From sidr-bounces@ietf.org Mon Apr 03 20:41:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQZbb-0005Nx-BG; Mon, 03 Apr 2006 20:41:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQZba-0005Ns-3c for sidr@ietf.org; Mon, 03 Apr 2006 20:41:10 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQZbZ-0007Ap-Pd for sidr@ietf.org; Mon, 03 Apr 2006 20:41:10 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.84.131.89]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FQZbU-0000Xn-5T; Mon, 03 Apr 2006 20:41:04 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <7.0.1.0.2.20060324222959.0344ca40@ripe.net> References: <6.2.0.14.2.20060222211102.02be4f00@kahuna.telstra.net> <6.2.0.14.2.20060324005247.02de6620@localhost> <7.0.1.0.2.20060324222959.0344ca40@ripe.net> Date: Mon, 3 Apr 2006 20:41:18 -0400 To: Henk Uijterwaal From: Stephen Kent Subject: Re: [sidr] One potential work item. Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: fenner@research.att.com, sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org At 10:41 PM +0100 3/24/06, Henk Uijterwaal wrote: >All, > >Since Geoff asked about work items for this group... > >One thing that I'd find particularly useful, is a requirements document >for RIRs. Assume that the RIRs will set up a PKI and hand out a (or more) >certificate(s) for each IP/AS allocation. > >* Vendors/protocol designers > = Requirements that will allow the certificates to be used with > {s|so|ps|...}BGP. I don't want to choose a protocol, but I do want > to make sure that we don't force people into a certain direction > before the various technologies are fully mature. SBGP called for use of X.509 certs with an extension equivalent to what was later defined in RFC 3779. soBGP dfeines several types of certs in the I-Ds that have been published, but none of them make use of IETF/ITU standard formats. So, the soBGP designers have to respond to the question of whether they are comfortable using IETF standards for certs, and whether the RFC 3779 extension representation of addresses and ASNs meets their requirements. psBGP assumes use of certs issued by registries to represent ASNs and addresses, and I don't think they have any problem with using X.509 certs and the 3779 extension. > >* LIRs/ISPs > = How do they see themselves use these certificates > = What would make them useful/useless. > = What happens if a block is transferred to a customer. > = What happens if resources are exchanged (traded) between ISPs. > = What should be common amongst all 5 RIRs. > = Interaction with IRRs and such > = Can they use certificates from other bodies, who controls their > identity. There are a lot of good questions here. I'll suggest some answers to some of them. A primary, near-term use of this data by ISPs is to use it to generate higher assurance route filters. By downloading certs, CRLs, and signed objects that address block holders use to declare which ASes are authorized to originate routes, each ISP can independently verify these route origination assertions, these can then be used to generate route filters. As holders of address space each ISP should sign objects that declare itself as the authorized originator of routes to its address space. An ISP also can request/require subscribers with portable address space (or address space originally allocated to another ISP) to present a signed object authorizing the ISP to advertise this address space that it does not hold, and to prove that the subscriber is the holder of the cert associated with the address space. this would help prevent social engineering attacks against ISPs re originating routes not held by subscribers. I'm sure others can describe additional ways ISPs can make use of the data. An ISP could transfer a block to a customer by issuing a cert to that customer. alternatively, the ISP could relinquish the block to a registry and have it transferred to the subscriber. both mechanisms can be accommodated via a PKI and it is more an operational (and political) decision as to which model should be employed. For transfer between ISPs, the same sort of mechanisms apply, although I'd suggest a registry-mediated transfer to keep things as clean as possible. all registries and ISPs need to follow a common cert policy for the PKI to have uniform semantics. however, each registry and ISP can adopt it's own procedures for cert issuance/renewal/revocation for its clients. I'd strongly suggest a unified, largely centralized repository system for certs, CRLs, and signed objects that attest to resource holdings. if every ISP needs to retrieve all of this data, then having it scattered over every ISP makes life awfully hard for the ISPs themselves. IRRs could hold the signed objects that represent authorizations to originate routes, as an adjunct to their current data. There may be other things IRRs could do with this data too. The PKI model I've suggested does not attest to identity. So trying to incorporate certs that attest to identity, but not to resource holdings, doesn't work very well. It's a case of mixing credentials. For example, I can use my passport ort my driver's license to identify myself as part of airport security. But, if I show the passport to the rental car folks they are not happy, because it is not a license to drive. >* Government bodies: > = Requirements on the PKI (EU, DHS, ...) > (We will hand out certificates that are used world-wide, so we better > make sure that they confirm to all relevant local regulations). there are no US regulations re issuance of certs used for authorization (vs. identification & authentication). EU regulations focus on identification & authentication as well, and specifically the use of certs for non-repudiation; the EU digital signature directive does not apply to these certs. so I don't know of any regulations that apply to issuance of these certs, because they are not for identification, and they definitely NOT for non-repudiation (which is the common focus of such regulation). >* Other expected use cases I suggest we focus exclusively on applications that want to make use of a PKI to verify claims of resource holdings allocated by the registry system, i.e., address space and ASNs. That is consistent with the charter of this WG re IDR security, and helps us avoid distractions. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Apr 18 18:30:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVyhz-0002BY-JH; Tue, 18 Apr 2006 18:30:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVyhy-0002BQ-5c; Tue, 18 Apr 2006 18:30:06 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVyhw-0001oC-Qo; Tue, 18 Apr 2006 18:30:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k3IMU1vP030223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Apr 2006 22:30:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FVyht-0004a0-MK; Tue, 18 Apr 2006 18:30:01 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Tue, 18 Apr 2006 18:30:01 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: sidr@ietf.org Subject: [Sidr] WG Action: Secure Inter-Domain Routing (sidr) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org A new IETF working group has been formed in the Routing Area. For additional information, please contact the Area Directors or the WG Chairs. +++ Secure Inter-Domain Routing (sidr) ==================================== Current Status: Active Working Group Chairs: Geoff Huston Sandra Murphy Routing Area Directors: Bill Fenner Ross Callon Routing Area Advisor: Ross Callon Technical Advisor: Steven Bellovin 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. The SIDR working group will develop security mechanisms which fulfill those requirements which have been agreed on by the RPSEC working group. In developing these mechanisms, the SIDR working group will take practical deployability into consideration. 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 Mar-07 Submit routing security architecture for publication as an Informational RFC May-07 Submit description of use certificate objects by this architecture as an Informational RFC June-07 Submit secure origination mechanism as a Proposed Standard Aug-07 Evaluate progress, recharter with new goals or shutdown. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr