From sidr-bounces@ietf.org Thu Feb 02 18:46:47 2006 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 1F4oA3-00051F-M1; Thu, 02 Feb 2006 18: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 1F4oA1-0004zv-KE for sidr@megatron.ietf.org; Thu, 02 Feb 2006 18: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 SAA27506 for ; Thu, 2 Feb 2006 18:44:55 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4oLI-0002qp-2o for sidr@ietf.org; Thu, 02 Feb 2006 18:58:24 -0500 Received: from gihm3.apnic.net (protege.telstra.net [203.50.0.194] (may be forged)) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k12NkC6i072880 for ; Fri, 3 Feb 2006 10:46:12 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20060203104252.02b23d80@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 03 Feb 2006 10:43:04 +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: b22590c27682ace61775ee7b453b40d3 Subject: [Sidr] 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, Alex and Bill have reported back on the IESG's consideration of the proposed SIDR Charter. They've asked us to see if we can submit a revised charter early next week that addresses the following comments: 1. Para that says: > Both strict hierarchical and distributed non- > hierarchical trust systems are intended to be supported within > this framework. should also say that the reason for this is that they are both needed, each for a different deployment model. 2. The charter speaks about authentication, but not about authorization, and it should. For reference the proposed charter is attached to this note The next note will detail suggested changes to the proposed charter to address these comments, for your consideration. Regards, 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 at ietf.org To Subscribe: sidr-request at 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 Thu Feb 02 18:47:03 2006 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 1F4oAJ-000552-Rt; Thu, 02 Feb 2006 18:47:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4oAJ-00053T-3n for sidr@megatron.ietf.org; Thu, 02 Feb 2006 18:47:03 -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 SAA27527 for ; Thu, 2 Feb 2006 18:45:19 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4oLg-0002ru-FB for sidr@ietf.org; Thu, 02 Feb 2006 18:58:49 -0500 Received: from gihm3.apnic.net (protege.telstra.net [203.50.0.194] (may be forged)) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k12NkkoB072888 for ; Fri, 3 Feb 2006 10:46:46 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20060203104613.02ceca80@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 03 Feb 2006 10:46:44 +1100 To: sidr@ietf.org From: Geoff Huston Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Subject: [Sidr] Re: 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, Here are the proposed edits to the SIDR Charter in response to the IESG comments. 1. Para that says: > Both strict hierarchical and distributed non- > hierarchical trust systems are intended to be supported within > this framework. should also say that the reason for this is that they are both needed, each for a different deployment model. Proposed to add: The intended support of both forms of trust models is to allow for the use of this form of routing security in diverse routing environments that have different underlying trust characteristics. 2. The charter speaks about authentication, but not about authorization, and it should. Proposed to alter the charter description at 3 points: 1. is that of the validity of the address prefix being advertised 2. and the existence of an 3. objects for supporting the distribution of authorization information The proposed revisied charter (with revision of the milestones also) is attached. regards, Geoff =========================================================================== Secure Inter-Domain Routing (sidr) Last Modified: 2006-02-03 (V5) 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 at ietf.org To Subscribe: sidr-request at 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 authority and validity of the address prefix being advertised, the validity of the originating Autonomous System | Number, and the existence of authorization in the form 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 authorization and authentication information. Both strict hierarchical and distributed non- hierarchical trust systems are intended to be supported within | this framework. The intended support of both forms of trust models | is to allow for the use of this form of routing security | in diverse routing environments that have different underlying | trust characteristics. 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: Aug-06 Submit initial draft on inter-domain routing security architecture Sep-06 Submit initial draft on certificate objects to be used within this architecture Sep-06 Submit initial draft on securing origination of routing information Jan-07 Submit routing security architecture for publication as an Informational RFC Mar-07 Submit description of use certificate objects by this architecture as an Informational RFC Apr-07 Submit secure origination mechanism as a Proposed Standard May-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 Thu Feb 02 19:45:39 2006 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 1F4p51-0002J3-RH; Thu, 02 Feb 2006 19:45:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4p4y-0002HO-Qn for sidr@megatron.ietf.org; Thu, 02 Feb 2006 19:45:38 -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 TAA05033 for ; Thu, 2 Feb 2006 19:43:51 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4pGI-00061n-Fo for sidr@ietf.org; Thu, 02 Feb 2006 19:57:20 -0500 Received: from [198.202.64.50] (dommiel.bbn.com [192.1.122.15]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k130itIC011268; Thu, 2 Feb 2006 19:45:05 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.0.14.2.20060203104613.02ceca80@kahuna.telstra.net> References: <6.2.0.14.2.20060203104613.02ceca80@kahuna.telstra.net> Date: Thu, 2 Feb 2006 19:44:45 -0500 To: Geoff Huston From: Stephen Kent Subject: [Sidr] Re: SIDR Charter Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 Geoff, I don't think we should say "the authority and validity of the address prefix being advertised, ..." because a prefix does not have authority per se. Similarly, the phrase "the validity of the originating Autonomous System Number..." sounds a bit odd, e.g., are any allocated AS numbers not "valid?" How about: "The basic security questions that can be posed regarding routing information are whether the originating Autonomous System is authorized to advertise an address prefix by the holder of that prefix, and whether the originating AS is accurately identified by the Autonomous System Number in the advertisement." The use of the term "strict hierarchical" sounds a bit pejorative. How about just "hierarchic" and "non-hierarchic" when discussing trust models later in the charter? Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Feb 02 21:01:37 2006 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 1F4qGX-0001di-RR; Thu, 02 Feb 2006 21:01:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4qGR-0001cL-VS for sidr@megatron.ietf.org; Thu, 02 Feb 2006 21:01:36 -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 UAA10472 for ; Thu, 2 Feb 2006 20:59:39 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4qRg-0000Ed-85 for sidr@ietf.org; Thu, 02 Feb 2006 21:13:10 -0500 Received: from gihm3.apnic.net (protege.telstra.net [203.50.0.194] (may be forged)) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k1320frS074956; Fri, 3 Feb 2006 13:00:41 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20060203123243.02c45858@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 03 Feb 2006 13:00:36 +1100 To: Stephen Kent From: Geoff Huston Subject: Re: [Sidr] Re: SIDR Charter In-Reply-To: References: <6.2.0.14.2.20060203104613.02ceca80@kahuna.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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:44 AM 3/02/2006, Stephen Kent wrote: >Geoff, > >I don't think we should say "the authority and validity of the address >prefix being advertised, ..." because a prefix does not have authority >per se. I was intending the sentence to parse with "authority" relating to "advertised" >Similarly, the phrase "the validity of the originating Autonomous System >Number..." sounds a bit odd, e.g., are any allocated AS numbers not "valid?" I'll defend those words - using unallocated AS numbers in are indeed invalid in the context of the public network, and the validity of the originating AS number is indeed an issue in this respect. i.e. while any allocated AS number is "valid", any unallocated AS number is "invalid". >How about: > >"The basic security questions that can be posed regarding routing >information are whether the originating Autonomous System is authorized >to advertise an address prefix by the holder of that prefix, and whether >the originating AS is accurately identified by the Autonomous System >Number in the advertisement." I still think there is a residual issue of validity of the originating AS and the address prefix here. i.e. you'd like to know if the prefix or the AS are bogons irrespective of the authorities. Using your formulation, I'd add a a second clause to the statement, as below "The basic security questions that can be posed regarding routing information are whether the originating Autonomous System is authorized to advertise an address prefix by the holder of that prefix, and whether the originating AS is accurately identified by the originating Autonomous System Number in the advertisement, and the validity of both the address prefix and the Autonomous System Number. Would this work for you? >The use of the term "strict hierarchical" sounds a bit pejorative. How >about just "hierarchic" and "non-hierarchic" when discussing trust models >later in the charter? sure thanks Steve Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Feb 03 11:58:11 2006 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 1F54GA-00045A-Ob; Fri, 03 Feb 2006 11:58:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F54G7-00042E-Jm for sidr@megatron.ietf.org; Fri, 03 Feb 2006 11:58:07 -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 LAA19945 for ; Fri, 3 Feb 2006 11:56:29 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F54Ri-0002iO-V7 for sidr@ietf.org; Fri, 03 Feb 2006 12:10:08 -0500 Received: from [198.202.64.16] (dommiel.bbn.com [192.1.122.15]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k13Gv9IE012171; Fri, 3 Feb 2006 11:57:41 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.0.14.2.20060203123243.02c45858@kahuna.telstra.net> References: <6.2.0.14.2.20060203104613.02ceca80@kahuna.telstra.net> <6.2.0.14.2.20060203123243.02c45858@kahuna.telstra.net> Date: Fri, 3 Feb 2006 11:53:15 -0500 To: Geoff Huston From: Stephen Kent Subject: Re: [Sidr] Re: SIDR Charter Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 1:00 PM +1100 2/3/06, Geoff Huston wrote: >At 11:44 AM 3/02/2006, Stephen Kent wrote: >>Geoff, >> >>I don't think we should say "the authority and validity of the >>address prefix being advertised, ..." because a prefix does not >>have authority per se. > >I was intending the sentence to parse with "authority" relating to >"advertised" Oh, I didn't parse it the same way, >>Similarly, the phrase "the validity of the originating Autonomous >>System Number..." sounds a bit odd, e.g., are any allocated AS >>numbers not "valid?" > >I'll defend those words - using unallocated AS numbers in are indeed >invalid in the context of the public network, and the validity of >the originating AS number is indeed an issue in this respect. i.e. >while any allocated AS number is "valid", any unallocated AS number >is "invalid". OK, good point. >>How about: >> >>"The basic security questions that can be posed regarding routing >>information are whether the originating Autonomous System is >>authorized to advertise an address prefix by the holder of that >>prefix, and whether the originating AS is accurately identified by >>the Autonomous System Number in the advertisement." > >I still think there is a residual issue of validity of the >originating AS and the address prefix here. i.e. you'd like to know >if the prefix or the AS are bogons irrespective of the authorities. >Using your formulation, I'd add a a second clause to the statement, >as below > >"The basic security questions that can be posed regarding routing >information are whether the originating Autonomous System is >authorized to advertise an address prefix by the holder of that >prefix, and whether the originating AS is accurately identified by > the originating Autonomous System Number in the advertisement, and >the validity of both the address prefix and the Autonomous System >Number. > > >Would this work for you? yes. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Feb 05 19:47:54 2006 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 1F5uXq-00083S-26; Sun, 05 Feb 2006 19:47:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5uXo-0007zg-0P for sidr@megatron.ietf.org; Sun, 05 Feb 2006 19:47:52 -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 TAA28366 for ; Sun, 5 Feb 2006 19:46:11 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5ujt-0005Yh-1h for sidr@ietf.org; Sun, 05 Feb 2006 20:00:21 -0500 Received: from gihm3.apnic.net (protege.telstra.net [203.50.0.194] (may be forged)) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k160kxIV057381; Mon, 6 Feb 2006 11:46:59 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20060206114351.02dc7118@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 06 Feb 2006 11:46:32 +1100 To: Alex Zinin , Bill Fenner From: Geoff Huston In-Reply-To: <1492352361.20060202145358@psg.com> References: <468895517.20060202094843@psg.com> <6.2.0.14.2.20060203071609.02fb36b0@kahuna.telstra.net> <1492352361.20060202145358@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: sidr@ietf.org Subject: [Sidr] Re: IESG review 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 At 09:53 AM 3/02/2006, Alex Zinin wrote: >Oh, and it would be great if we could have the new text >early next week, so we wouldn't have any extra delay with external >review. Hi Alex, Its now early next week - so here's a revised charter that reflects the IESG comments, as you've requested. regards, Geoff ============================================ Secure Inter-Domain Routing (sidr) Last Modified: 2006-02-06 (V6) 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 at ietf.org To Subscribe: sidr-request at 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 are whether the originating Autonomous System is authorized to advertise an address prefix by the holder of that prefix, whether the originating AS is accurately identified by the originating Autonomous System Number in the advertisement, and the validity of both the address prefix and the Autonomous System Number. 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 authorization and authentication information. Both hierarchic and distributed non- hierarchic trust systems are intended to be supported within this framework. The intended support of both forms of trust models is to allow for the use of this framework for routing security in diverse routing environments that have different underlying trust characteristics. 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: Aug-06 Submit initial draft on inter-domain routing security architecture Sep-06 Submit initial draft on certificate objects to be used within this architecture Sep-06 Submit initial draft on securing origination of routing information Jan-07 Submit routing security architecture for publication as an Informational RFC Mar-07 Submit description of use certificate objects by this architecture as an Informational RFC Apr-07 Submit secure origination mechanism as a Proposed Standard May-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 Wed Feb 08 12:52:27 2006 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 1F6tUQ-000107-Us; Wed, 08 Feb 2006 12:52:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6tUO-0000xW-AQ for sidr@megatron.ietf.org; Wed, 08 Feb 2006 12:52:24 -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 MAA15068 for ; Wed, 8 Feb 2006 12:50:42 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6th0-0006JL-4O for sidr@ietf.org; Wed, 08 Feb 2006 13:05:27 -0500 Received: from [147.28.0.62] (helo=usmovnazinin.alcatel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6tUJ-000FjJ-JH; Wed, 08 Feb 2006 17:52:20 +0000 Date: Wed, 8 Feb 2006 09:52:02 -0800 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <95925572.20060208095202@psg.com> To: Geoff Huston In-Reply-To: <6.2.0.14.2.20060206114351.02dc7118@kahuna.telstra.net> References: <468895517.20060202094843@psg.com> <6.2.0.14.2.20060203071609.02fb36b0@kahuna.telstra.net> <1492352361.20060202145358@psg.com> <6.2.0.14.2.20060206114351.02dc7118@kahuna.telstra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: 7bit Cc: Bill Fenner , sidr@ietf.org Subject: [Sidr] Re: IESG review of SIDR charter X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin 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, Geoff! -- Alex http://www.psg.com/~zinin Sunday, February 5, 2006, 4:46:32 PM, Geoff Huston wrote: > At 09:53 AM 3/02/2006, Alex Zinin wrote: >>Oh, and it would be great if we could have the new text >>early next week, so we wouldn't have any extra delay with external >>review. > Hi Alex, > Its now early next week - so here's a revised charter that reflects the IESG > comments, as you've requested. > regards, > Geoff > ============================================ > Secure Inter-Domain Routing (sidr) > Last Modified: 2006-02-06 (V6) > 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 at ietf.org > To Subscribe: sidr-request at 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 > are whether the originating Autonomous System is authorized to > advertise an address prefix by the holder of that prefix, whether > the originating AS is accurately identified by the originating > Autonomous System Number in the advertisement, and the validity of > both the address prefix and the Autonomous System Number. 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 authorization and > authentication information. Both hierarchic and distributed non- > hierarchic trust systems are intended to be supported within this > framework. The intended support of both forms of trust models is to > allow for the use of this framework for routing security in diverse > routing environments that have different underlying trust > characteristics. > 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: > Aug-06 Submit initial draft on inter-domain routing security > architecture > Sep-06 Submit initial draft on certificate objects to be used > within this architecture > Sep-06 Submit initial draft on securing origination of routing > information > Jan-07 Submit routing security architecture for publication as an > Informational RFC > Mar-07 Submit description of use certificate objects by this > architecture as an Informational RFC > Apr-07 Submit secure origination mechanism as a Proposed Standard > May-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 Wed Feb 08 15:09:10 2006 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 1F6vck-0005Jm-NI; Wed, 08 Feb 2006 15:09:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6vcg-0005If-M4; Wed, 08 Feb 2006 15:09: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 PAA27992; Wed, 8 Feb 2006 15:07:24 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6vpK-0003Pa-WF; Wed, 08 Feb 2006 15:22:11 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1F6vcf-0003PR-8Z; Wed, 08 Feb 2006 15:09:05 -0500 Content-Type: text/plain Mime-Version: 1.0 To: IETF Announcement list From: IESG Secretary Message-Id: Date: Wed, 08 Feb 2006 15:09:05 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: sidr@ietf.org Subject: [Sidr] WG Review: Secure Inter-Domain Routing (sidr) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org 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 new IETF working group has been proposed in the Routing Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by February 15th. +++ Secure Inter-Domain Routing (sidr) =================================== Current Status: Proposed Working Group 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 at ietf.org To Subscribe: sidr-request at 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 are whether the originating Autonomous System is authorized to advertise an address prefix by the holder of that prefix, whether the originating AS is accurately identified by the originating Autonomous System Number in the advertisement, and the validity of both the address prefix and the Autonomous System Number. 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 authorization and authentication information. Both hierarchic and distributed non- hierarchic trust systems are intended to be supported within this framework. The intended support of both forms of trust models is to allow for the use of this framework for routing security in diverse routing environments that have different underlying trust characteristics. 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: Aug-06 Submit initial draft on inter-domain routing security architecture Sep-06 Submit initial draft on certificate objects to be used within this architecture Sep-06 Submit initial draft on securing origination of routing information Jan-07 Submit routing security architecture for publication as an Informational RFC Mar-07 Submit description of use certificate objects by this architecture as an Informational RFC Apr-07 Submit secure origination mechanism as a Proposed Standard May-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 Wed Feb 22 05:10:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBqwt-0000QU-B0; Wed, 22 Feb 2006 05:10:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBqws-0000Q1-38 for sidr@ietf.org; Wed, 22 Feb 2006 05:10:18 -0500 Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBqwq-0003CY-CT for sidr@ietf.org; Wed, 22 Feb 2006 05:10:18 -0500 Received: from gihm3.apnic.net (dhcp10.potaroo.net [203.10.60.10]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k1MAADiL032929 for ; Wed, 22 Feb 2006 21:10:13 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20060222210647.02bf2338@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 22 Feb 2006 21:10:12 +1100 To: sidr@ietf.org From: Geoff Huston In-Reply-To: <95925572.20060208095202@psg.com> References: <468895517.20060202094843@psg.com> <6.2.0.14.2.20060203071609.02fb36b0@kahuna.telstra.net> <1492352361.20060202145358@psg.com> <6.2.0.14.2.20060206114351.02dc7118@kahuna.telstra.net> <95925572.20060208095202@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Sidr] Assembling the SIDR agenda for IETF 65 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org Hi, At IETF65 its either going to be a 2nd BOF or an initial meeting of the SIDR Working Group, depending on the rate of progress of the SIDR charter through the IESG.. Either way I'd like to see what topics folk want to talk about / present on at the upcoming SIDR meeting, as I'd like to submit the agenda for the meeting at the start of next week. So offers of agenda items / presentations for SIDR would be very much appreciated - _now_ thanks, Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Feb 22 05:12:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBqyw-0000WE-Gg; Wed, 22 Feb 2006 05:12:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBqyu-0000W8-Q1 for sidr@ietf.org; Wed, 22 Feb 2006 05:12:24 -0500 Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBqyu-0003N9-3N for sidr@ietf.org; Wed, 22 Feb 2006 05:12:24 -0500 Received: from gihm3.apnic.net (dhcp10.potaroo.net [203.10.60.10]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k1MACMQd032955 for ; Wed, 22 Feb 2006 21:12:22 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20060222211102.02be4f00@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 22 Feb 2006 21:12:14 +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.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Sidr] Assembling the SIDR agenda for IETF 65 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org And as a reminder, here's what I suggested a few weeks back :.... Geoff Its been a while, so as a refresher, the BOF notes from November are at http://www3.ietf.org/proceedings/05nov/sidr.html The proto WG Charter as passed to the ADs is at http://www.ietf.org/mail-archive/web/sidr/current/msg00020.html So I'd like to take this opportunity to call for agenda items for the 2nd BOF, and in particular it makes sense to start to look at the first three proposed work items and see if there are contributions to these topics, namely in the areas of: - inter-domain routing security architecture - certificate objects to be used within this architecture - securing origination of routing information Also, if anyone has any input relating to operational experiences in this area (such as the recent incident concerning PANIX as discussed on the NANOG list) this also may be useful for the BOF. many thanks, Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr