From sidr-bounces@ietf.org Thu Dec 01 10:54: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 1Ehqli-0001tD-TN; Thu, 01 Dec 2005 10:54:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehqlf-0001rS-U5 for sidr@megatron.ietf.org; Thu, 01 Dec 2005 10:54:46 -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 KAA08119 for ; Thu, 1 Dec 2005 10:53:57 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ehr6B-0002eB-Jf for sidr@ietf.org; Thu, 01 Dec 2005 11:15:55 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id jB1FsEIE021142; Thu, 1 Dec 2005 10:54:15 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.0.14.2.20051128203425.02acf120@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> <6.2.0.14.2.20051128203425.02acf120@kahuna.telstra.net> Date: Thu, 1 Dec 2005 10:54:10 -0500 To: Geoff Huston From: Stephen Kent Subject: Re: [Sidr] V3 draft of 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: cab78e1e39c4b328567edb48482b6a69 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 8:36 PM +1100 11/28/05, 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? > >thanks, > > Geoff Geoff, We have various models for certificate (and CRL) distribution from PKI work and from security protocols like S/MIME, TLS/SSL, and IPsec. In the case of security protocols we have seen a tendency to tailor distribution models to the application environment, while the PKI work has offered generic repository models. For SIDR we need to examine the ways relying parties (those who want to make use of certs) will act, and I expect we will need to tailor a distribution model for this application context. Unlike most other applications that make use of a PKI, all RPs need access to all certs (and CRLs) on a regular basis, in order to validate the "certification objects" for all the participants. In the public Internet, one probably needs a distribution model that is uniform, rather than a list of optional approaches, to avoid burdening RPs with a need to support multiple ways of acquiring this data. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Dec 02 03:22:55 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 1Ei6Bz-0008Oc-LY; Fri, 02 Dec 2005 03:22:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei6Bt-0008IQ-N2 for sidr@megatron.ietf.org; Fri, 02 Dec 2005 03:22: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 DAA21998 for ; Fri, 2 Dec 2005 03:22:02 -0500 (EST) Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei6WW-00056O-Us for sidr@ietf.org; Fri, 02 Dec 2005 03:44:10 -0500 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id jB28MjvK024670; Fri, 2 Dec 2005 00:22:45 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id jB28MiFq024667; Fri, 2 Dec 2005 00:22:45 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 2 Dec 2005 00:22:44 -0800 (PST) From: "william(at)elan.net" To: =?ISO-8859-1?B?zfXEyA==?= In-Reply-To: <7A7A7A38134E244784EDAC428C538AE90152DD58@mail.ndsc.com.cn> Message-ID: References: <7A7A7A38134E244784EDAC428C538AE90152DD58@mail.ndsc.com.cn> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: nanog@merit.edu, sidr@ietf.org Subject: [Sidr] Re: S-BGP and IP prefix aggregation 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'm cross-posting this to SIDR BOF (future SIDR WG) list as that seems to be the most appropriate forum to discuss this issue] On Fri, 2 Dec 2005, wrote: > I have a question about S-BGP. When IP prefix is aggregated, and a > S-BGP speaker receives a route announcement with the aggregated ip > prefix, > > how does it verify the authority of the AS to announce the IP prefix. > The aggregated IP prefix should have not address attestation. With rare exceptions almost all aggregation happens by ISP that has been allocated larger block and which it sub-allocated to its customers (or decided to break of and announce subparts from multiple datacenters), so in this case ISP (ASN) would obviously be able to provide a permission [sign cert] to announce that larger block. There are however some rare exceptions, for example I know of ip block in legacy class-c space that UUNET is announcing as /16 aggregate but where it actually consists of a number of smaller ip blocks assigned (direct assignment from RIR) to several different organizations. I always assumed myself that those running SIDR aware routers in such cases would not be doing aggregation - i.e. no aggregation if each ip block in the aggregate has permission for announcement from different entity. An alternative for sbgp design could be that aggregating ASN would create special self-signing cert for such aggregate block and that cert would have special attribute(s) indicating list of all sub-blocks and reference to all certs that "make" this aggregate block. Then verifying router in such a case would go through and verify each one of those sub-block certs (and those sub-block certs would have to be such that they give permission for announcing the block from that sub-block owner to aggregating ASN). -- 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 Fri Dec 02 03:42:16 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 1Ei6Ui-0007AF-8u; Fri, 02 Dec 2005 03:42:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei6UX-0006xX-FM for sidr@megatron.ietf.org; Fri, 02 Dec 2005 03:42:15 -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 DAA23704 for ; Fri, 2 Dec 2005 03:41:17 -0500 (EST) Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei6pA-0005q8-9p for sidr@ietf.org; Fri, 02 Dec 2005 04:03:26 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc14) with SMTP id <2005120208414001400hb4i1e>; Fri, 2 Dec 2005 08:41:49 +0000 In-Reply-To: References: <7A7A7A38134E244784EDAC428C538AE90152DD58@mail.ndsc.com.cn> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Sidr] Re: S-BGP and IP prefix aggregation Date: Fri, 2 Dec 2005 00:41:37 -0800 To: "william(at)elan.net" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org, =?ISO-8859-1?B?zfXEyA==?= , nanog@merit.edu 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 > > An alternative for sbgp design could be that aggregating ASN would > create special self-signing cert for such aggregate block and that > cert would have special attribute(s) indicating list of all sub- > blocks and reference > to all certs that "make" this aggregate block. Then verifying router > in such a case would go through and verify each one of those sub-block > certs (and those sub-block certs would have to be such that they > give permission for announcing the block from that sub-block owner > to aggregating ASN). > Advertising an aggregate that is not specifically assigned to you is known as "proxy aggregation". William has given a good description of what's required above, but it needs a further enhancement in that proxy aggregation will frequently need to happen in several locations for the aggregate to have any true impact on routing. In graph theoretic terms, proxy aggregation must form a "cut set" topologically around the longer prefixes to contain them and prevent them from being distributed throughout the network. Thus, any security mechanism needs to provide some means for indicating that an entire set of ASes may legitimately be advertising a proxy aggregate prefix. How one determines the appropriate set of ASes that are authorized is another interesting administrative issue that needs to be resolved. Tony _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Dec 02 10:47:20 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 1EiD84-0005je-Cx; Fri, 02 Dec 2005 10:47:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiD80-0005gi-Rs for sidr@megatron.ietf.org; Fri, 02 Dec 2005 10:47:19 -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 KAA09208 for ; Fri, 2 Dec 2005 10:46:27 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiDSh-0003lE-It for sidr@ietf.org; Fri, 02 Dec 2005 11:08:40 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id jB2FkTIC002068; Fri, 2 Dec 2005 10:46:29 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <7A7A7A38134E244784EDAC428C538AE90152DD58@mail.ndsc.com.cn> Date: Fri, 2 Dec 2005 10:38:02 -0500 To: "william(at)elan.net" From: Stephen Kent Subject: [Sidr] Re: S-BGP and IP prefix aggregation 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: 4d87d2aa806f79fed918a62e834505ca Cc: sidr@ietf.org, =?iso-8859-1?Q?=CD=F5=C4=C8?= , nanog@merit.edu 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 12:22 AM -0800 12/2/05, william(at)elan.net wrote: >[I'm cross-posting this to SIDR BOF (future SIDR WG) list as that seems > to be the most appropriate forum to discuss this issue] > >On Fri, 2 Dec 2005, wrote: > >>I have a question about S-BGP. When IP prefix is aggregated, and a >>S-BGP speaker receives a route announcement with the aggregated ip >>prefix, >> >>how does it verify the authority of the AS to announce the IP >>prefix. The aggregated IP prefix should have not address >>attestation. > >With rare exceptions almost all aggregation happens by ISP that has been >allocated larger block and which it sub-allocated to its customers >(or decided to break of and announce subparts from multiple >datacenters), so in this case ISP (ASN) would obviously be able to >provide a permission [sign cert] to announce that larger block. > >There are however some rare exceptions, for example I know of ip block >in legacy class-c space that UUNET is announcing as /16 aggregate but >where it actually consists of a number of smaller ip blocks assigned >(direct assignment from RIR) to several different organizations. > >I always assumed myself that those running SIDR aware routers in such cases >would not be doing aggregation - i.e. no aggregation if each ip >block in the aggregate has permission for announcement from >different entity. > >An alternative for sbgp design could be that aggregating ASN would >create special self-signing cert for such aggregate block and that >cert would have special attribute(s) indicating list of all >sub-blocks and reference >to all certs that "make" this aggregate block. Then verifying router >in such a case would go through and verify each one of those sub-block >certs (and those sub-block certs would have to be such that they >give permission for announcing the block from that sub-block owner >to aggregating ASN). > I don't know if we should be going into quite this much detail at this stage. However, I would avoid suggestions to use of self-signed certs in the way suggested above. Remember that a self-signed cert has relatively little security value in a PKI. We use a self-signed cert primarily to represent a public key for a trust anchor, because it allows reuse of the cert format and that's convenient. Also, certs (vs. other forms of signed objects) are probably not the best way to represent the authorization of an AS to advertise address space. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Dec 02 11:44:27 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 1EiE1L-0002gA-SP; Fri, 02 Dec 2005 11:44:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiE1L-0002g5-Bo for sidr@megatron.ietf.org; Fri, 02 Dec 2005 11:44:27 -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 LAA15168 for ; Fri, 2 Dec 2005 11:43:39 -0500 (EST) Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiEM2-0005Zk-8M for sidr@ietf.org; Fri, 02 Dec 2005 12:05:52 -0500 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id jB2GhwhM031757; Fri, 2 Dec 2005 08:43:58 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id jB2GhwWc031754; Fri, 2 Dec 2005 08:43:58 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 2 Dec 2005 08:43:57 -0800 (PST) From: "william(at)elan.net" To: Stephen Kent Subject: Re: [Sidr] Re: S-BGP and IP prefix aggregation In-Reply-To: Message-ID: References: <7A7A7A38134E244784EDAC428C538AE90152DD58@mail.ndsc.com.cn> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: =?ISO-8859-1?B?zfXEyA==?= , 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 Fri, 2 Dec 2005, Stephen Kent wrote: >> An alternative for sbgp design could be that aggregating ASN would create >> special self-signing cert for such aggregate block and that cert would have >> special attribute(s) indicating list of all sub-blocks and reference >> to all certs that "make" this aggregate block. Then verifying router >> in such a case would go through and verify each one of those sub-block >> certs (and those sub-block certs would have to be such that they give >> permission for announcing the block from that sub-block owner to >> aggregating ASN). >> > I don't know if we should be going into quite this much detail at this stage. Well, the BoF charter discussions would be higher priority but seeing as it seemed to have already been sent and discussions closed, why not discuss some possible protocol features. > However, I would avoid suggestions to use of self-signed certs in the way > suggested above. Remember that a self-signed cert has relatively little > security value in a PKI. I agree. But in this case that this cert has little value only works in our favor as security software would more clearly see that it needs to disregard it "security value" and focus on the security provided by the referenced certs for portions of aggregated block as being the key to deciding if the ip block announcement is ok or not. BTW - self-signed as I used it above also includes when ASN uses its own organization's key (which could be signed by RIR) to create this cert (i.e. its signed by ASN about ASN), it does not have to be real self-signed cert in the x509 way. > We use a self-signed cert primarily to represent a public key for a > trust anchor, because it allows reuse of the cert format and that's > convenient. Also, certs (vs. other forms of signed objects) are > probably not the best way to represent the authorization of an AS to > advertise address space. I personally often use the word "cert" to mean any type of PKI signed structured object (no matter if its x509 cert or not). The exactly format is definitely something to be discussed and decided by the WG and is a reason why I said that decisions on how to publish and propagate authorization data and the format should be part of the WG work area. -- 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 Fri Dec 02 14:31:01 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 1EiGcX-00053r-3V; Fri, 02 Dec 2005 14:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiGcU-00053e-Uj for sidr@megatron.ietf.org; Fri, 02 Dec 2005 14:30:59 -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 OAA05145 for ; Fri, 2 Dec 2005 14:30:11 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiGxD-0003NV-UO for sidr@ietf.org; Fri, 02 Dec 2005 14:52:25 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id jB2JUKIE015684; Fri, 2 Dec 2005 14:30:22 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <7A7A7A38134E244784EDAC428C538AE90152DD58@mail.ndsc.com.cn> Date: Fri, 2 Dec 2005 14:30:19 -0500 To: "william(at)elan.net" From: Stephen Kent Subject: Re: [Sidr] Re: S-BGP and IP prefix aggregation 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: d185fa790257f526fedfd5d01ed9c976 Cc: =?iso-8859-1?Q?=CD=F5=C4=C8?= , 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 8:43 AM -0800 12/2/05, william(at)elan.net wrote: >On Fri, 2 Dec 2005, Stephen Kent wrote: > >>>An alternative for sbgp design could be that aggregating ASN would >>>create special self-signing cert for such aggregate block and that >>>cert would have special attribute(s) indicating list of all >>>sub-blocks and reference >>>to all certs that "make" this aggregate block. Then verifying router >>>in such a case would go through and verify each one of those sub-block >>>certs (and those sub-block certs would have to be such that they >>>give permission for announcing the block from that sub-block owner >>>to aggregating ASN). >>> >>I don't know if we should be going into quite this much detail at this stage. > >Well, the BoF charter discussions would be higher priority but >seeing as it seemed to have already been sent and discussions >closed, why not discuss some possible protocol features. OK. >>However, I would avoid suggestions to use of self-signed certs in >>the way suggested above. Remember that a self-signed cert has >>relatively little security value in a PKI. > >I agree. But in this case that this cert has little value only works >in our favor as security software would more clearly see that it >needs to >disregard it "security value" and focus on the security provided by >the referenced certs for portions of aggregated block as being the >key to >deciding if the ip block announcement is ok or not. there is a lot of open source software to process certs, and it would not react well to this sort of use of a self-signed cert. >BTW - self-signed as I used it above also includes when ASN uses its >own organization's key (which could be signed by RIR) to create this >cert (i.e. its signed by ASN about ASN), it does not have to be real >self-signed cert in the x509 way. I'd ask that we stick with the standards-based definitions for PKI objects, whenever possible, to minimize confusion. >>We use a self-signed cert primarily to represent a public key for a >>trust anchor, because it allows reuse of the cert format and that's >>convenient. Also, certs (vs. other forms of signed objects) are >>probably not the best way to represent the authorization of an AS >>to advertise address space. > >I personally often use the word "cert" to mean any type of PKI signed >structured object (no matter if its x509 cert or not). The exactly >format is definitely something to be discussed and decided by the WG >and is a reason why I said that decisions on how to publish and >propagate >authorization data and the format should be part of the WG work area. One can use the term cert more broadly, but it adds confusion to an already complex topic. We're certainly free to define digitally signed objects to meet application-specific requirements, just as S/MIME makes use of CMS as a basis for secure e-mail formats. But it makes the discussion more precise if we use the term cert (public key cert is more precise but the qualifier is usually omitted) to refer to signed structures that bind a public key to a set of attributes. The security ADs (who will eventually review our documents) frown on the creation of new mechanisms or data structures when there are existing IETF standards that meet the needs of an application :-). Note that the IETF has explored various cert formats in the past. For example, we had the SPKI WG for a while, but it closed and yielded no standards track RFCs. Most IETF security protocols (e.g., IPsec, S/MIME, TLS) make use of X.509 certs. The PKIX WG has developed both profiles for X.509 standards as well as IETF-specific protocols for these certs, e.g., OCSP and SCVP. When Harald asked if Geoff envisioned use of the RFC 3779 cert extension to represent address space and AS number data, the response was "yes." So, given this background I think it's reasonable to assume use of X.509 certs unless we find them to be lacking in some serious fashion. Stve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Dec 02 14:39: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 1EiGlA-0002Ig-Il; Fri, 02 Dec 2005 14:39:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiGl9-0002FN-6K for sidr@megatron.ietf.org; Fri, 02 Dec 2005 14:39: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 OAA06073 for ; Fri, 2 Dec 2005 14:39:07 -0500 (EST) Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiH5s-0003h2-EY for sidr@ietf.org; Fri, 02 Dec 2005 15:01:21 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc11) with SMTP id <2005120219393901100ai3r3e>; Fri, 2 Dec 2005 19:39:44 +0000 In-Reply-To: References: <7A7A7A38134E244784EDAC428C538AE90152DD58@mail.ndsc.com.cn> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Sidr] Re: S-BGP and IP prefix aggregation Date: Fri, 2 Dec 2005 11:39:37 -0800 To: Stephen Kent X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?B?zfXEyA==?= , 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 > there is a lot of open source software to process certs, and it > would not react well to this sort of use of a self-signed cert. Gents, Could I help elide this discussion? If we do proxy aggregation correctly and coordinate it amongst a number of different ISPs, then the cert should not be self-signed. In fact, it needs to derive authorization from the coordinating body. One might imagine an "IETF Proxy Aggregation" entity which would sign these certs. Regards, Tony _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Dec 02 16:00: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 1EiI1W-0001tS-82; Fri, 02 Dec 2005 16:00:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiI1U-0001sx-H5 for sidr@megatron.ietf.org; Fri, 02 Dec 2005 16:00: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 QAA15607 for ; Fri, 2 Dec 2005 16:00:03 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiIMB-0006tB-5s for sidr@ietf.org; Fri, 02 Dec 2005 16:22:16 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id jB2L09IC021062; Fri, 2 Dec 2005 16:00:10 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <7A7A7A38134E244784EDAC428C538AE90152DD58@mail.ndsc.com.cn> Date: Fri, 2 Dec 2005 15:26:45 -0500 To: Tony Li From: Stephen Kent Subject: Re: [Sidr] Re: S-BGP and IP prefix aggregation 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: 9466e0365fc95844abaf7c3f15a05c7d 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:39 AM -0800 12/2/05, Tony Li wrote: >>there is a lot of open source software to process certs, and it >>would not react well to this sort of use of a self-signed cert. > > >Gents, > >Could I help elide this discussion? > >If we do proxy aggregation correctly and coordinate it amongst a >number of different ISPs, then the >cert should not be self-signed. In fact, it needs to derive >authorization from the coordinating body. > >One might imagine an "IETF Proxy Aggregation" entity which would >sign these certs. > >Regards, >Tony We started with the notion that address space holders authorize ISPs to originate routes. When aggregation of routes takes place at a point that is not known by the address space holders, we need to agree on who makes sense to authorize the aggregation. I would not necessarily expect there to be a single entity for such authorization, since the address space holders, route originators, and aggregation points are potentially independent and distinct. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Dec 02 19:17:34 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 1EiL5q-0000tT-89; Fri, 02 Dec 2005 19:17:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiL5p-0000tL-IZ for sidr@megatron.ietf.org; Fri, 02 Dec 2005 19:17:33 -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 TAA20718 for ; Fri, 2 Dec 2005 19:16:46 -0500 (EST) Received: from portolanetworks.com ([66.121.157.205] helo=portola.portolanetworks.tv) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiLQZ-0002Gb-Uj for sidr@ietf.org; Fri, 02 Dec 2005 19:39:02 -0500 Received: from [192.168.2.22] ([66.121.157.194]) by portola.portolanetworks.tv with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Dec 2005 16:12:19 -0800 In-Reply-To: References: <7A7A7A38134E244784EDAC428C538AE90152DD58@mail.ndsc.com.cn> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3D985088-FC94-47B0-9D68-557391E1E6CB@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Sidr] Re: S-BGP and IP prefix aggregation Date: Fri, 2 Dec 2005 16:16:58 -0800 To: Stephen Kent X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 03 Dec 2005 00:12:19.0171 (UTC) FILETIME=[39830B30:01C5F79E] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit 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 >> If we do proxy aggregation correctly and coordinate it amongst a >> number of different ISPs, then the >> cert should not be self-signed. In fact, it needs to derive >> authorization from the coordinating body. >> >> One might imagine an "IETF Proxy Aggregation" entity which would >> sign these certs. > > We started with the notion that address space holders authorize > ISPs to originate routes. When aggregation of routes takes place at > a point that is not known by the address space holders, we need to > agree on who makes sense to authorize the aggregation. I would not > necessarily expect there to be a single entity for such > authorization, since the address space holders, route originators, > and aggregation points are potentially independent and distinct. Steve, For proxy aggregation to work in any useful manner, there is an entire perimeter, not a single point where the aggregation takes place. Thus, there needs to be coordination of all entities around that perimeter. For anti-trust issues alone, I'd suggest that this would need to be a single, collaborative entity. Tony _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Dec 04 22:30:20 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 1Ej73U-0005cI-Hl; Sun, 04 Dec 2005 22:30:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ej73T-0005bv-Id for sidr@megatron.ietf.org; Sun, 04 Dec 2005 22:30:19 -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 WAA19859 for ; Sun, 4 Dec 2005 22:29:30 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ej7Oe-0006hb-I4 for sidr@ietf.org; Sun, 04 Dec 2005 22:52:15 -0500 Received: from gihm3.apnic.net (rsdhcp5.telstra.net [203.50.0.197]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id jB53TNUR072627 for ; Mon, 5 Dec 2005 14:29:23 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051205142655.02898ef8@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 05 Dec 2005 14:28:58 +1100 To: sidr@ietf.org From: Geoff Huston Subject: Re: [Sidr] Re: S-BGP and IP prefix aggregation In-Reply-To: References: <7A7A7A38134E244784EDAC428C538AE90152DD58@mail.ndsc.com.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 03:43 AM 3/12/2005, william(at)elan.net wrote: >Well, the BoF charter discussions would be higher priority but seeing as >it seemed to have already been sent and discussions closed, why not >discuss some possible protocol features. The ADs asked for a draft charter by the end of November, so, yes, the draft charter has now been shipped to the Routing Area ADs. I have heard nothing back at this stage. Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Dec 04 22:40: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 1Ej7D1-0007nZ-TC; Sun, 04 Dec 2005 22:40:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ej7Cs-0007mA-Pa for sidr@megatron.ietf.org; Sun, 04 Dec 2005 22:40:10 -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 WAA20589 for ; Sun, 4 Dec 2005 22:39:13 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ej7Y6-0006xj-3I for sidr@ietf.org; Sun, 04 Dec 2005 23:01:58 -0500 Received: from gihm3.apnic.net (rsdhcp5.telstra.net [203.50.0.197]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id jB53daHF072798; Mon, 5 Dec 2005 14:39:36 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051205143023.02ae7150@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 05 Dec 2005 14:39:19 +1100 To: Tony Li , Stephen Kent From: Geoff Huston Subject: Re: [Sidr] Re: S-BGP and IP prefix aggregation In-Reply-To: References: <7A7A7A38134E244784EDAC428C538AE90152DD58@mail.ndsc.com.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: =?iso-8859-1?Q?=CD=F5=C4=C8?= , 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 06:39 AM 3/12/2005, Tony Li wrote: >>there is a lot of open source software to process certs, and it >>would not react well to this sort of use of a self-signed cert. > > >Gents, > >Could I help elide this discussion? > >If we do proxy aggregation correctly and coordinate it amongst a >number of different ISPs, then the >cert should not be self-signed. In fact, it needs to derive >authorization from the coordinating body. > >One might imagine an "IETF Proxy Aggregation" entity which would sign >these certs. So what are we looking for in an proxy aggregated announcement? - that the aggregate is made of up only of valid addresses? (i.e. that an aggregate cannot span unallocated address space) yes? no? - that the aggregate was formed only by component prefixes where valid routing authorities existed? Or a heterogenous collection of prefixes, some with authority credentials and some not? - Should the aggregate prefix announcement have associated credentials? Tony above appears to be suggestion that this is a coordinated action with a set of entities who then jointly attest to the validity of the authority action, if I am reading his note correctly. Is proxy aggregation truly a coordinated action? Or do various forms of unilateration proxy aggregation exist? - in an environment where the security module is intended to present the origination credentials to a receiver to allow the receiver to check the validity of an announcement, is it possible to validate the credentials (and the correctness) of a proxy aggregator? Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 05 03:00:14 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 1EjBGg-0003RK-8p; Mon, 05 Dec 2005 03:00:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjBGc-0003R8-P6 for sidr@megatron.ietf.org; Mon, 05 Dec 2005 03:00:13 -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 CAA13190 for ; Mon, 5 Dec 2005 02:59:19 -0500 (EST) Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjBbs-0006TK-3h for sidr@ietf.org; Mon, 05 Dec 2005 03:22:09 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc11) with SMTP id <2005120507595001100aecqfe>; Mon, 5 Dec 2005 07:59:55 +0000 In-Reply-To: <6.2.0.14.2.20051205143023.02ae7150@kahuna.telstra.net> References: <7A7A7A38134E244784EDAC428C538AE90152DD58@mail.ndsc.com.cn> <6.2.0.14.2.20051205143023.02ae7150@kahuna.telstra.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <72F46031-6FBE-4137-B0F1-DB3463380894@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Sidr] Re: S-BGP and IP prefix aggregation Date: Sun, 4 Dec 2005 23:59:48 -0800 To: Geoff Huston X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?B?zfXEyA==?= , 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, > So what are we looking for in an proxy aggregated announcement? > > - that the aggregate is made of up only of valid addresses? (i.e. > that an aggregate cannot span unallocated address space) yes? no? I'd argue that as long as it has properly credentials, it doesn't matter. It is up to the coordinating body to determine what to proxy aggregate and to determine the ASes that will be authorized to advertise the aggregate. > - that the aggregate was formed only by component prefixes where > valid routing authorities existed? Or a heterogenous collection of > prefixes, some with authority credentials and some not? Since the longer prefixes are hopefully not being globally circulated, it would be difficult to verify these properties externally. Certainly, accepting such an aggregate is placing operational trust in the advertiser, above and beyond what we would expect from normal prefix distribution. > - Should the aggregate prefix announcement have associated > credentials? Tony above appears to be suggestion that this is a > coordinated action with a set of entities who then jointly attest > to the validity of the authority action, if I am reading his note > correctly. Is proxy aggregation truly a coordinated action? Or do > various forms of unilateration proxy aggregation exist? We've tried proxy aggregation as a unilateral function before and even as an semi-coordinated multilateral function. It failed miserably due to the traffic engineering side effects. Hopefully, if we coordinate our efforts and anticipate and compensate for those results prior to putting an aggregate in place, we will be able to avoid this. > - in an environment where the security module is intended to > present the origination credentials to a receiver to allow the > receiver to check the validity of an announcement, is it possible > to validate the credentials (and the correctness) of a proxy > aggregator? It should be, as I outlined above, by presenting a delegation from a trusted central coordinating body. Tony _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 05 11:43: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 1EjJRX-0001mx-7S; Mon, 05 Dec 2005 11:43:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjJRU-0001mG-Vw for sidr@megatron.ietf.org; Mon, 05 Dec 2005 11:43: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 LAA11233 for ; Mon, 5 Dec 2005 11:43:06 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjJmn-0008UB-NR for sidr@ietf.org; Mon, 05 Dec 2005 12:05:59 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id jB5GhcIC020255; Mon, 5 Dec 2005 11:43:39 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <3D985088-FC94-47B0-9D68-557391E1E6CB@tony.li> References: <7A7A7A38134E244784EDAC428C538AE90152DD58@mail.ndsc.com.cn> <3D985088-FC94-47B0-9D68-557391E1E6CB@tony.li> Date: Mon, 5 Dec 2005 11:43:29 -0500 To: Tony Li From: Stephen Kent Subject: Re: [Sidr] Re: S-BGP and IP prefix aggregation 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: 21c69d3cfc2dd19218717dbe1d974352 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 4:16 PM -0800 12/2/05, Tony Li wrote: >>>If we do proxy aggregation correctly and coordinate it amongst a >>>number of different ISPs, then the >>>cert should not be self-signed. In fact, it needs to derive >>>authorization from the coordinating body. >>> >>>One might imagine an "IETF Proxy Aggregation" entity which would >>>sign these certs. >> >>We started with the notion that address space holders authorize >>ISPs to originate routes. When aggregation of routes takes place at >>a point that is not known by the address space holders, we need to >>agree on who makes sense to authorize the aggregation. I would not >>necessarily expect there to be a single entity for such >>authorization, since the address space holders, route originators, >>and aggregation points are potentially independent and distinct. > > >Steve, > >For proxy aggregation to work in any useful manner, there is an >entire perimeter, not a single point >where the aggregation takes place. Thus, there needs to be >coordination of all entities around that >perimeter. For anti-trust issues alone, I'd suggest that this would >need to be a single, collaborative >entity. > >Tony Tony, We seem to agree that the goal is to ensure that each AS advertising itself as the origin for a route is authorized to do so. While it may be necessary to introduce an additional entity to attest to this authorization in the case of proxy aggregation, I'd hate to have us assume this as a starting point. Also, from a security perspective, it is preferable to rely upon as few parties as possible, to minimize opportunities for failure. So, I suggest we work our way through the easy cases and then deal with proxy aggregation, to determine if it is necessary to introduce an additional entity to issue a credential for proxy aggregation. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 05 12:27:30 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 1EjK7e-0007yn-SF; Mon, 05 Dec 2005 12:27:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjK7c-0007yi-QU for sidr@megatron.ietf.org; Mon, 05 Dec 2005 12:27:28 -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 MAA16371 for ; Mon, 5 Dec 2005 12:26:37 -0500 (EST) Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjKSt-0001aE-TZ for sidr@ietf.org; Mon, 05 Dec 2005 12:49:31 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc11) with SMTP id <20051205172708011005ls9ee>; Mon, 5 Dec 2005 17:27:08 +0000 In-Reply-To: References: <7A7A7A38134E244784EDAC428C538AE90152DD58@mail.ndsc.com.cn> <3D985088-FC94-47B0-9D68-557391E1E6CB@tony.li> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Sidr] Re: S-BGP and IP prefix aggregation Date: Mon, 5 Dec 2005 09:27:06 -0800 To: Stephen Kent X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit 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 > So, I suggest we work our way through the easy cases and then deal > with proxy aggregation, to determine if it is necessary to > introduce an additional entity to issue a credential for proxy > aggregation. No objection to the ordering. Since the easy cases are rooted at the RIRs and proxy aggregation would add one to this set, I'm not seeing the big deal. Also, it seems clear that the RIRs are not appropriate body to reach consensus on routing operational policy, so the involvement of some other organization seems inevitable. Tony _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 05 13:13:15 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 1EjKpv-0005UF-0a; Mon, 05 Dec 2005 13:13:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjKpt-0005UA-R6 for sidr@megatron.ietf.org; Mon, 05 Dec 2005 13:13:13 -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 NAA22287 for ; Mon, 5 Dec 2005 13:12:21 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjLBC-0003N7-EV for sidr@ietf.org; Mon, 05 Dec 2005 13:35:15 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id jB5ICrIE025910; Mon, 5 Dec 2005 13:12:54 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <7A7A7A38134E244784EDAC428C538AE90152DD58@mail.ndsc.com.cn> <3D985088-FC94-47B0-9D68-557391E1E6CB@tony.li> Date: Mon, 5 Dec 2005 13:06:38 -0500 To: Tony Li From: Stephen Kent Subject: Re: [Sidr] Re: S-BGP and IP prefix aggregation 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: 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 9:27 AM -0800 12/5/05, Tony Li wrote: >>So, I suggest we work our way through the easy cases and then deal >>with proxy aggregation, to determine if it is necessary to >>introduce an additional entity to issue a credential for proxy >>aggregation. > > >No objection to the ordering. Since the easy cases are rooted at >the RIRs and proxy aggregation >would add one to this set, I'm not seeing the big deal. Also, it >seems clear that the RIRs are not >appropriate body to reach consensus on routing operational policy, >so the involvement of >some other organization seems inevitable. > >Tony I'd never suggest that the RIRs are involved with routing policy per se. I suggest that we model address space (and AS #) allocation through the registries (RIRs and NIR/LIRs) and via ISPs as a first step. Once we have agreement on generating, distributing, and validating resource holder credentials, then we can move onto dealing with authorization to originate routes, both directly and in the proxy case we've been discussing. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr