Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA08903 for ; Fri, 28 Jan 2000 19:07:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9159B5DDC1; Fri, 28 Jan 2000 19:07:05 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 26C305DD8E; Fri, 28 Jan 2000 19:07:04 -0500 (EST) Received: from mlsrv1.avici.com (unknown [208.246.215.9]) by segue.merit.edu (Postfix) with ESMTP id A2D865DD8E for ; Fri, 28 Jan 2000 19:06:55 -0500 (EST) Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id TAA26676; Fri, 28 Jan 2000 19:06:06 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id TAA37218; Fri, 28 Jan 2000 19:07:59 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200001290007.TAA37218@curtis-lt.avici.com> To: "Benjamin Black" Cc: "Vijay Gill" , danny@ice.ip.qwest.net, idr@merit.edu Reply-To: curtis@avici.com Subject: Re: Secure BGP -- Internet Drafts In-reply-to: Your message of "Thu, 27 Jan 2000 19:48:22 PST." <00dc01bf6942$85b73e40$0a45a8c0@layer8.net> Date: Fri, 28 Jan 2000 19:07:59 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message <00dc01bf6942$85b73e40$0a45a8c0@layer8.net>, "Benjamin Black" writes : > > > > The algorithm cost is based on prefixes, if the cost of the computation > > based on prefix growth is less than Moore's law, there isn't a problem. > > > > It is actually proportional to the number of prefixes multiplied by the > average AS path length as the computations are carried out for each AS in > the path. > > Ben Minor point - Its the number of unique prefix and advertising AS advertised to the router via EBGP times the average AS path length. If the number of peer AS grows and/or the average AS path length grows, then the amount of computation grows even if the number of prefixes remains constant. Processors are getting faster but if BGP convergence time is already noticably slowed when simply checking prefixes against a list (where search is roder log(N) unless the implementation is severely broken), then there is some question as to whether the additional cryptographic processing would be a welcome change. When a BGP update arrives it can have about 500 prefixes. A list of all prefixes that you might consider taking from a given peer is generally on the order of 10,000 entries or less. Looking at a linked list you'd do do 500*10,000 or 5,000,000 operations per BGP update. This would kill routers so no one does this anymore (I hope). With a patricia trie search, expected are 500*14 comparisons (14 is expected depth of a perfectly balanced trie of 16,384). For each peer providing full routes, that would be 700,000 comparisons. For 50 peer AS, that would be 35,000,000. This is a few seconds of processing. With SBGP you have to find the entry for a prefix to get the public key for that prefix (essentially verifying that the origin AS was expected for that prefix), then apply the public key for each AS along the AS path. The AS path is the same for the whole BGP update, but prefixes must be signed individually. The cryptographic operation is likely to be computationally more expensive than the 14 comparisons needed to find an entry. My only point in bringing this up (again) is that if looking up a prefix in a tree has a noticable effect on convergence time, then the cryptographic computation will have a greater effect on convergence time. This may still be acceptable, particularly as processors get faster and/or additional processors assist in cryptographic computation, but it might be worth noting. Aggregation is problematic since signatures cannot be aggregated. They have to be tossed or also kept in deaggregated form. If they are kept in deaggregated form, this begs the question as to whether the router needs to verify the signatures chains within the aggregate and what it does if some are valid but some are not. I'm assuming that the deaggregated signatures can be tossed and verification of aggregates is the only requirement. There is still another issue of current practice. If we accept that verification of aggregates is sufficient and further propose that in some (most) uses verification of the advertising AS is sufficient, we need to seriously consider whether incremental change to current practice (maybe not widely enough used practice) is a better approach. X.509 may be no better than the IRR as a means of distribution in this application and there is at least limited use of the IRR. Verification of peer through BGP MD5 and verification of the prefix, advertising AS, and optionally AS path verification is a step in the direction of SBPG and requires only a MD5 digest across the entire BGP4 packet and check against the IRR (through configured policy lists or the near real time mirror if a router vendor decided to do that). [Aside: Of course, I'd rather see the use of the authentication and authorization model in RFC2725 "Routing Policy System Security" in the IRR and use of the distribution (out of band distribution as far as the routers are concerned) using draft-ietf-rps-dist-06.txt "Routing Policy System Replication" for distribution of policy and the prefix lists to the routers using the light weight mirror capability described in rps-dist (see Appendix A.4 "Transaction Redistribution"). But I might be biased about this.] I don't see these things as barriers to publications as experimental. The document does acknowledge that it is proposing a computaionally intensive solution. A bit of analysis in an appendix might be helpful but not necessarily a requirement. Minor question to the authors: In configuration what does "Per peer, no not send attestations" mean? btw- The policy section is a bit thin. :) speaking on behalf of myself, Curtis Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA19881 for ; Fri, 28 Jan 2000 05:27:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id ADB4B5DDA9; Fri, 28 Jan 2000 05:26:36 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8DBC25DDA5; Fri, 28 Jan 2000 05:26:36 -0500 (EST) Received: from amtsun.amt.ru (amtsun.amt.ru [212.111.64.19]) by segue.merit.edu (Postfix) with ESMTP id 9F8F85DDA3 for ; Fri, 28 Jan 2000 05:26:33 -0500 (EST) Received: (from zinin@localhost) by amtsun.amt.ru (8.8.8/8.7.3.1) id NAA05213; Fri, 28 Jan 2000 13:26:15 +0300 (MSK) From: Alexey Zinin Message-Id: <200001281026.NAA05213@amtsun.amt.ru> Subject: Re: BGP:tie-breaking algorithm enhancement proposal To: aretana@cisco.com (Alvaro Retana) Date: Fri, 28 Jan 100 13:26:15 +0300 (MSK) Cc: idr@merit.edu In-Reply-To: from "Alvaro Retana" at Jan 27, 0 10:04:52 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Sender: owner-idr@merit.edu Precedence: bulk Alvaro: I know of at least one IX which has suffered and still is suffering from this change in the path selection process (I was handling this case). I think what you propose may be a useful enhancement, but any changes to the route selection algo must be implemented with a configuration option, allowing to revert to standard behavior, since people may (and actually do) rely on the Router-ID as the determinating factor. Alex. > > > The current BGP4 draft (draft-ietf-idr-bgp4-09) reads: > > ------------------------------------------------------------------- > 9.1.2.1 Breaking Ties (Phase 2) > ..... > The tie-breaking algorithm begins by considering all equally > preferable routes and then selects routes to be removed from > consideration. The algorithm terminates as soon as only one route > remains in consideration. The criteria must be applied in the order > specified. > > ..... > c) If at least one of the candidate routes was received from an > external peer in a neighboring autonomous system, remove from > consideration all routes which were received from internal peers. > > d) Remove from consideration all routes other than the route that > was advertised by the BGP speaker whose BGP Identifier has the > lowest value. > ------------------------------------------------------------------- > > I would like to propose the following enhancement (to be put in place of > the last step listed above): > > d) If the remaining routes are all external, remove from consideration > all routes except the one that was received first and any others with > the same BGP Identifier as it (the one received first). > > e) Remove from consideration all routes other than the ones advertised > by the BGP speaker whose BGP Identifier has the lowest value. > > > > In summary, the change will allow a BGP speaker to keep the oldest > external route as the best path, if all the other conditions are the same. > Except for the case where more than one route is received from the same > eBGP peer. > > In keeping the oldest external, the number of unnecesary routing updates > can be lowered. Note that by advertising a new bestpath (if all the > attributes, except the BGP Identifier, are the same), the exit point will > not change. > > In the case where the BGP Identifier is the same, then the "normal" > procedure is used. > > Any/all comment are welcome. :-) > > Alvaro. > > > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA18150 for ; Fri, 28 Jan 2000 03:09:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9740C5DDA2; Fri, 28 Jan 2000 03:08:58 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 353285DDA3; Fri, 28 Jan 2000 03:08:58 -0500 (EST) Received: from mailserver-ng.cs.umbc.edu (mailserver-ng.cs.umbc.edu [130.85.100.230]) by segue.merit.edu (Postfix) with ESMTP id 0D70F5DDA2 for ; Fri, 28 Jan 2000 03:08:56 -0500 (EST) Received: from localhost (wrath@localhost) by mailserver-ng.cs.umbc.edu (8.9.3/8.9.3) with SMTP id DAA27665; Fri, 28 Jan 2000 03:08:53 -0500 (EST) Date: Fri, 28 Jan 2000 03:08:53 -0500 (EST) From: Vijay Gill To: Bruce Cole Cc: idr@merit.edu Subject: Re: Secure BGP -- Internet Drafts In-Reply-To: <200001280755.XAA25275@dakine.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk On Thu, 27 Jan 2000, Bruce Cole wrote: > > There isn't any real reason why the current CPU trends cannot be imported > > into the routers. As someone at a promising local startup said, we can > > walk down to Fry's and pick up 2x the cpu every year or so. > > Last I remember from the IDR working group meeting in Orlando, these > proposed protocol extensions impacted BGP convergence time severely. > I believe it was admitted that it would take ~24 hours for BGP to > be able to receive full routing information. > > We use off the shelf CPUs in our systems, but I doubt that we could > yet provide such a feature without significant impact to convergence > time. If that is no longer true, I'd like to see someone report the > numbers. Given intrumentation of some BGP implementations that I am working on at UUNET, I'd have to agree. The key result (which was fairly unexpected by most people) was that the _computation_ was not the bottleneck, but rather, the dissemination and convergence as a whole. Given you are under NDA with us, I could probably send you a copy of the scaling analysis. > In the mean time, Juniper Networks does not want to consider this draft, > and doesn't want to see it an IDR working group draft. I concurr. /vijay Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA15021 for ; Thu, 27 Jan 2000 22:53:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id EB2A35DE09; Thu, 27 Jan 2000 22:53:09 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5CC535DE14; Thu, 27 Jan 2000 22:53:09 -0500 (EST) Received: from tristero.cryptocourier.com (black-3.dsl.speakeasy.net [216.231.56.189]) by segue.merit.edu (Postfix) with SMTP id 1C4F45DE09 for ; Thu, 27 Jan 2000 22:53:00 -0500 (EST) Received: (qmail 24744 invoked from network); 28 Jan 2000 03:54:03 -0000 Received: from ae.layer8.net (HELO ae) (192.168.69.10) by tristero.cryptocourier.com with SMTP; 28 Jan 2000 03:54:03 -0000 Message-ID: <00e601bf6942$d71b1ea0$0a45a8c0@layer8.net> Reply-To: "Benjamin Black" From: "Benjamin Black" To: "Susan Hares" , Cc: , References: Subject: Re: Secure BGP -- Internet Drafts Date: Thu, 27 Jan 2000 19:50:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-idr@merit.edu Precedence: bulk Could anyone comment on how SBGP is superior to generating prefix and AS path lists based on registries and using SSL between BGP peers? It appears to me that SBGP offers no significant benefit, but incurs significant costs in changes to BGP implementations and increased demands on routers. Ben > > Here are a few drafts on BBN's work on Secure BGP. > Should these drafts become IDR working group drafts? > Please send comments to the list. > > > Sue Hares > > -------------- > > Message-Id: > Date: Fri, 29 Oct 1999 00:14:15 -0400 > To: idr@merit.edu > From: Karen Seo > Subject: Secure BGP -- Internet Drafts > Cc: sbgp@po2.bbn.com > > Hello, > > Over the past year, we (Charlie Lynn and Luis Sanchez) have made > presentations on our Secure BGP (S-BGP) work at several IDR WG sessions. We > would now like to submit two internet drafts on Secure BGP (see below) to > the IDR working group for review/feedback and consideration for adoption > as IDR working group documents. We have sent both to the IETF secretariat > and also put copies at our web site: > http://www.ir.bbn.com/projects/sbgp/ > > It should be noted that we have prepared these (individual submission) > I-Ds, based on our experience with a prototype implementation and initial > testing, including some performance measurements. Thus, we feel that the > design is now sufficiently mature to warrant requesting that the IDR WG > formally consider adopting it as the basis for a work item, oriented > towards providing high quality security for BGP. > > Please let us know if you have questions/comments. Thank you, > Karen > > 1. Secure BGP (S-BGP) -- Charles Lynn, Joanne Mikkelson, Karen Seo, > draft-clynn-s-bgp-protocol-00.txt, October 1999. > > Abstract > > The Border Gateway Protocol (BGP), which is used to distribute routing > information between autonomous systems (ASes), is a critical component > of the Internet's routing infrastructure. It is highly vulnerable to a > variety of malicious attacks both in theory and in practice, due to > the lack of a scalable means of verifying the authenticity and > legitimacy of BGP control traffic. This document is a protocol > specification for Secure BGP (S-BGP), an extension to BGP-4. S-BGP > adheres to the principle of least privilege and uses countermeasures > that create an authentication and authorization system that addresses > most of the security problems associated with BGP. To facilitate > adoption and deployment, S-BGP is designed to minimize the overhead > (processing, bandwidth, storage) added by its > > 2. X.509 Extensions for Authorization of IP Addresses, AS Numbers, and > Routers within an AS -- Charles Lynn, draft-clynn-bgp-x509-auth-01.txt, > October 1999. > > Abstract > > This document defines three X.509 v3 Certificate Extensions. The > first binds a list of IP Address blocks to the public key of the > subject of a certificate. The second binds a list of Autonomous > System Numbers to the public key of the subject of a certificate. > The third binds a BGP Router Identifier and an Autonomous System > Number to the public key of the subject of a certificate. Third > parties, e.g., BGP routers, may use these certificates to verify > that the holder of the private key corresponding to the public > key in the certificate has been properly authorized to use > resources specified in the certificate extension. > > > > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA15011 for ; Thu, 27 Jan 2000 22:53:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id C600C5DD99; Thu, 27 Jan 2000 22:52:46 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 817CF5DDA9; Thu, 27 Jan 2000 22:52:46 -0500 (EST) Received: from mlsrv1.avici.com (unknown [208.246.215.9]) by segue.merit.edu (Postfix) with ESMTP id 83C335DD99 for ; Thu, 27 Jan 2000 22:52:44 -0500 (EST) Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id WAA00803; Thu, 27 Jan 2000 22:52:43 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id WAA36377; Thu, 27 Jan 2000 22:54:33 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200001280354.WAA36377@curtis-lt.avici.com> To: Vivek Menezes Cc: "'idr@merit.edu'" Reply-To: curtis@avici.com Subject: Re: Problems with Rfc 2439 In-reply-to: Your message of "Thu, 27 Jan 2000 14:51:34 PST." <6342F12F9359D311990B009027A1B9B6105039@monterey.pluris.com> Date: Thu, 27 Jan 2000 22:54:33 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message <6342F12F9359D311990B009027A1B9B6105039@monterey.pluris.com>, Vivek Menezes writes: > Hi, > I have found a few problems in the calculations in rfc 2439 "BGP route flap > damping". Could the authors please make the changes. > > 1. page 18. calculation of the value of ceiling should be > > ceiling = reuse * (exp (( T-hold/decay-half-life) * log(2) )) > > 2. page 20 calculation of reuse-index-array[j] should be > > reuse-index-array[j] = integer ((decay-half-life / reuse-time-granularity) * > log( 1 / (1 + (j/scale-factor))) / log(1/2)) > > The value of reuse is not required in the above equation. > > 3. The lines in the rfc following the above equation on page 20 should read > > "Divide the current figure of merit by the reuse". and not "Divide the > current figure of merit by the cutoff". > > Thanks > > Vivek Menezes. Thanks. I'll take a look at these. Curtis Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA14997 for ; Thu, 27 Jan 2000 22:51:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id EE9F75DD94; Thu, 27 Jan 2000 22:50:49 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9B6575DD99; Thu, 27 Jan 2000 22:50:49 -0500 (EST) Received: from tristero.cryptocourier.com (black-3.dsl.speakeasy.net [216.231.56.189]) by segue.merit.edu (Postfix) with SMTP id 6F8155DD94 for ; Thu, 27 Jan 2000 22:50:47 -0500 (EST) Received: (qmail 24723 invoked from network); 28 Jan 2000 03:51:46 -0000 Received: from ae.layer8.net (HELO ae) (192.168.69.10) by tristero.cryptocourier.com with SMTP; 28 Jan 2000 03:51:46 -0000 Message-ID: <00dc01bf6942$85b73e40$0a45a8c0@layer8.net> Reply-To: "Benjamin Black" From: "Benjamin Black" To: "Vijay Gill" , Cc: References: Subject: Re: Secure BGP -- Internet Drafts Date: Thu, 27 Jan 2000 19:48:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-idr@merit.edu Precedence: bulk > > The algorithm cost is based on prefixes, if the cost of the computation > based on prefix growth is less than Moore's law, there isn't a problem. > It is actually proportional to the number of prefixes multiplied by the average AS path length as the computations are carried out for each AS in the path. Ben Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA10826 for ; Thu, 27 Jan 2000 18:04:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2C5405DDC5; Thu, 27 Jan 2000 18:04:00 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DAD1E5DDF9; Thu, 27 Jan 2000 18:03:59 -0500 (EST) Received: from ice.ip.qwest.net (ice.ip.qwest.net [216.111.66.200]) by segue.merit.edu (Postfix) with ESMTP id E80235DDC5 for ; Thu, 27 Jan 2000 18:03:52 -0500 (EST) Received: from ice.ip.qwest.net (localhost [127.0.0.1]) by ice.ip.qwest.net (8.9.3/8.9.3) with ESMTP id QAA04270; Thu, 27 Jan 2000 16:06:51 -0700 (MST) Message-Id: <200001272306.QAA04270@ice.ip.qwest.net> X-Mailer: exmh version 2.0.2 2/24/98 To: Vijay Gill Cc: idr@merit.edu From: Danny McPherson Reply-To: danny@ice.ip.qwest.net Subject: Re: Secure BGP -- Internet Drafts Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Jan 2000 16:06:51 -0700 Sender: owner-idr@merit.edu Precedence: bulk > There isn't any real reason why the current CPU trends cannot be imported > into the routers. As someone at a promising local startup said, we can > walk down to Fry's and pick up 2x the cpu every year or so. > > cost is based on prefixes, if the cost of the computation > based on prefix growth is less than Moore's law, there isn't a problem. Again, I'm not disagreeing with anything. I'd love to see data detailing performance of an actual implementation, one which completely accounts for a typical deployment in an ISP network. I'll gladly provide anyone interested in performing these simulations with a perspective of typical number of iBGP/eBGP peers and routes your simulations. -danny Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA10698 for ; Thu, 27 Jan 2000 17:55:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 844285DDDE; Thu, 27 Jan 2000 17:55:01 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3CAAE5DDC5; Thu, 27 Jan 2000 17:55:01 -0500 (EST) Received: from mailserver-ng.cs.umbc.edu (mailserver-ng.cs.umbc.edu [130.85.100.230]) by segue.merit.edu (Postfix) with ESMTP id 6B7D35DDDE for ; Thu, 27 Jan 2000 17:54:59 -0500 (EST) Received: from localhost (wrath@localhost) by mailserver-ng.cs.umbc.edu (8.9.3/8.9.3) with SMTP id RAA17485; Thu, 27 Jan 2000 17:54:58 -0500 (EST) Date: Thu, 27 Jan 2000 17:54:57 -0500 (EST) From: Vijay Gill To: danny@ice.ip.qwest.net Cc: idr@merit.edu Subject: Re: Secure BGP -- Internet Drafts In-Reply-To: <200001271726.KAA03029@ice.ip.qwest.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk On Thu, 27 Jan 2000, Danny McPherson wrote: > > I seem to recall Curtis, coincidentally now with Avici, voicing some concerns > at an IDR WG meeting well over a year ago [somewhere] when the BBN folks > presented the previously referenced drafts. His concerns, regarding CPU > resources required for update processing, as well the model proposed > offsetting the benefits of aggregation, were shared among many providers, and > still stand today. I think Ben's hit on the larger part of the issues that > folks who would actually deploy this would/should be concerned with. There isn't any real reason why the current CPU trends cannot be imported into the routers. As someone at a promising local startup said, we can walk down to Fry's and pick up 2x the cpu every year or so. > While I'm in complete agreement that something absolutely has to be done in > this area, I'm not sure if this is the right approach. Though, because I > currently don't have a better answer for this "psuedo in-band" UPDATE > authentication, I guess I can't complain much. Then again, modeling an > implementation with this approach and providing some projections as to what > resources would be required will probably tip the scales in one direction or > the other. The algorithm cost is based on prefixes, if the cost of the computation based on prefix growth is less than Moore's law, there isn't a problem. /vijay Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA10654 for ; Thu, 27 Jan 2000 17:52:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id AC3DC5DDA6; Thu, 27 Jan 2000 17:52:29 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 66CC55DDC5; Thu, 27 Jan 2000 17:52:29 -0500 (EST) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by segue.merit.edu (Postfix) with ESMTP id 285955DDA6 for ; Thu, 27 Jan 2000 17:52:27 -0500 (EST) Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id OAA00995 for ; Thu, 27 Jan 2000 14:51:34 -0800 (PST) Received: by monterey.pluris.com with Internet Mail Service (5.5.2448.0) id ; Thu, 27 Jan 2000 14:51:34 -0800 Message-ID: <6342F12F9359D311990B009027A1B9B6105039@monterey.pluris.com> From: Vivek Menezes To: "'idr@merit.edu'" Subject: Problems with Rfc 2439 Date: Thu, 27 Jan 2000 14:51:34 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk Hi, I have found a few problems in the calculations in rfc 2439 "BGP route flap damping". Could the authors please make the changes. 1. page 18. calculation of the value of ceiling should be ceiling = reuse * (exp (( T-hold/decay-half-life) * log(2) )) 2. page 20 calculation of reuse-index-array[j] should be reuse-index-array[j] = integer ((decay-half-life / reuse-time-granularity) * log( 1 / (1 + (j/scale-factor))) / log(1/2)) The value of reuse is not required in the above equation. 3. The lines in the rfc following the above equation on page 20 should read "Divide the current figure of merit by the reuse". and not "Divide the current figure of merit by the cutoff". Thanks Vivek Menezes. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA07215 for ; Thu, 27 Jan 2000 14:49:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id DEFF05DDD0; Thu, 27 Jan 2000 14:49:21 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 96BC25DDDE; Thu, 27 Jan 2000 14:49:21 -0500 (EST) Received: from mlsrv1.avici.com (unknown [208.246.215.9]) by segue.merit.edu (Postfix) with ESMTP id 6AB2E5DDD0 for ; Thu, 27 Jan 2000 14:49:14 -0500 (EST) Received: from [10.1.1.15] (h000502e28374.ne.mediaone.net [24.147.124.132]) by mlsrv1.avici.com (8.8.5/8.8.4) with SMTP id OAA07164; Thu, 27 Jan 2000 14:48:38 -0500 (EST) Message-Id: <200001271948.OAA07164@mlsrv1.avici.com> Subject: Re: Secure BGP -- Internet Drafts Date: Thu, 27 Jan 2000 14:49:15 -0500 x-sender: hank@mailhost.avici.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Hank Zannini To: "Avi Freedman" Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-idr@merit.edu Precedence: bulk > >That's true, but Randy is still correct. Think of it as the groundwork - >Randy is pointing out one of the rules that enhances the ability of the >individuals involved in working groups to function more smoothly. > >Avi I apologized to Randy and to the list for making a protocol error. It was a draft and not a standard yet [Grin]. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA06871 for ; Thu, 27 Jan 2000 14:29:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 368A45DDF5; Thu, 27 Jan 2000 14:29:00 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 39F245DDFD; Thu, 27 Jan 2000 14:28:59 -0500 (EST) Received: from miata.procket.com (miata.procket.com [205.253.146.45]) by segue.merit.edu (Postfix) with ESMTP id 551995DEF5 for ; Thu, 27 Jan 2000 14:28:50 -0500 (EST) Received: (from tli@localhost) by miata.procket.com (8.9.3/8.9.3) id LAA09192; Thu, 27 Jan 2000 11:28:48 -0800 Date: Thu, 27 Jan 2000 11:28:48 -0800 Message-Id: <200001271928.LAA09192@miata.procket.com> X-Authentication-Warning: miata.procket.com: tli set sender to tli@miata.procket.com using -f From: Tony Li To: Hank@avici.com Cc: randy@psg.com, idr@merit.edu In-reply-to: <200001271925.OAA05860@mlsrv1.avici.com> (message from Hank Zannini on Thu, 27 Jan 2000 14:26:30 -0500) Subject: Re: Secure BGP -- Internet Drafts References: <200001271925.OAA05860@mlsrv1.avici.com> Sender: owner-idr@merit.edu Precedence: bulk Companies are not welcome at the IETF. Tony Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA06846 for ; Thu, 27 Jan 2000 14:27:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id A41FD5DDA8; Thu, 27 Jan 2000 14:26:42 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5E42E5DDD0; Thu, 27 Jan 2000 14:26:42 -0500 (EST) Received: from mlsrv1.avici.com (unknown [208.246.215.9]) by segue.merit.edu (Postfix) with ESMTP id 9894E5DDA8 for ; Thu, 27 Jan 2000 14:26:35 -0500 (EST) Received: from [10.1.1.15] (h000502e28374.ne.mediaone.net [24.147.124.132]) by mlsrv1.avici.com (8.8.5/8.8.4) with SMTP id OAA05860; Thu, 27 Jan 2000 14:25:48 -0500 (EST) Message-Id: <200001271925.OAA05860@mlsrv1.avici.com> Subject: Re: Secure BGP -- Internet Drafts Date: Thu, 27 Jan 2000 14:26:30 -0500 x-sender: hank@mailhost.avici.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Hank Zannini To: "Randy Bush" Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-idr@merit.edu Precedence: bulk >> I [We - Avici] certainly support > >the ietf is made up of individual experts, not companies. > >randy > No but it's companies that ultimately implement something and demonstrate interoperability for a standard. Cheers, Hank A sharp tongue sometimes cuts its own throat. *********************************************************** * Hank Zannini - FOUNDER E-mail Hank@Avici.com * * Vice President Business Dev. MAIN +1-978-964-2000 * * Avici Systems, Inc. VOICE +1-978-964-2222 * * 101 Billerica Ave Hank's Follow Me +1-603-890-5539 * * Building # 6 * * N. Billerica, MA 01862 Fax +1-978-964-2100 * * * * http://www.Avici.com * *********************************************************** Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA06558 for ; Thu, 27 Jan 2000 14:10:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 38E685DE06; Thu, 27 Jan 2000 13:51:09 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EDC325DE14; Thu, 27 Jan 2000 13:10:11 -0500 (EST) Received: from jindo.cisco.com (jindo.cisco.com [171.69.11.73]) by segue.merit.edu (Postfix) with ESMTP id BD00B5DE59 for ; Thu, 27 Jan 2000 13:08:27 -0500 (EST) Received: from aretana-u10.cisco.com (aretana-u10.cisco.com [161.44.24.15]) by jindo.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id KAA15369 for ; Thu, 27 Jan 2000 10:04:45 -0800 (PST) Date: Thu, 27 Jan 2000 10:04:52 -0800 (PST) From: Alvaro Retana To: idr@merit.edu Subject: BGP:tie-breaking algorithm enhancement proposal Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk The current BGP4 draft (draft-ietf-idr-bgp4-09) reads: ------------------------------------------------------------------- 9.1.2.1 Breaking Ties (Phase 2) ..... The tie-breaking algorithm begins by considering all equally preferable routes and then selects routes to be removed from consideration. The algorithm terminates as soon as only one route remains in consideration. The criteria must be applied in the order specified. ..... c) If at least one of the candidate routes was received from an external peer in a neighboring autonomous system, remove from consideration all routes which were received from internal peers. d) Remove from consideration all routes other than the route that was advertised by the BGP speaker whose BGP Identifier has the lowest value. ------------------------------------------------------------------- I would like to propose the following enhancement (to be put in place of the last step listed above): d) If the remaining routes are all external, remove from consideration all routes except the one that was received first and any others with the same BGP Identifier as it (the one received first). e) Remove from consideration all routes other than the ones advertised by the BGP speaker whose BGP Identifier has the lowest value. In summary, the change will allow a BGP speaker to keep the oldest external route as the best path, if all the other conditions are the same. Except for the case where more than one route is received from the same eBGP peer. In keeping the oldest external, the number of unnecesary routing updates can be lowered. Note that by advertising a new bestpath (if all the attributes, except the BGP Identifier, are the same), the exit point will not change. In the case where the BGP Identifier is the same, then the "normal" procedure is used. Any/all comment are welcome. :-) Alvaro. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA05087 for ; Thu, 27 Jan 2000 12:39:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id C0AF95DF7B; Thu, 27 Jan 2000 12:29:52 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BC0EE5DF37; Thu, 27 Jan 2000 12:27:40 -0500 (EST) Received: from ice.ip.qwest.net (ice.ip.qwest.net [216.111.66.200]) by segue.merit.edu (Postfix) with ESMTP id 294165DDD0 for ; Thu, 27 Jan 2000 12:26:34 -0500 (EST) Received: from ice.ip.qwest.net (localhost [127.0.0.1]) by ice.ip.qwest.net (8.9.3/8.9.3) with ESMTP id KAA03029 for ; Thu, 27 Jan 2000 10:26:23 -0700 (MST) Message-Id: <200001271726.KAA03029@ice.ip.qwest.net> X-Mailer: exmh version 2.0.2 2/24/98 To: idr@merit.edu From: Danny McPherson Reply-To: danny@ice.ip.qwest.net Subject: Re: Secure BGP -- Internet Drafts Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Jan 2000 10:26:23 -0700 Sender: owner-idr@merit.edu Precedence: bulk I seem to recall Curtis, coincidentally now with Avici, voicing some concerns at an IDR WG meeting well over a year ago [somewhere] when the BBN folks presented the previously referenced drafts. His concerns, regarding CPU resources required for update processing, as well the model proposed offsetting the benefits of aggregation, were shared among many providers, and still stand today. I think Ben's hit on the larger part of the issues that folks who would actually deploy this would/should be concerned with. While I'm in complete agreement that something absolutely has to be done in this area, I'm not sure if this is the right approach. Though, because I currently don't have a better answer for this "psuedo in-band" UPDATE authentication, I guess I can't complain much. Then again, modeling an implementation with this approach and providing some projections as to what resources would be required will probably tip the scales in one direction or the other. In response to Hank's comments, sure, SS7ish functionality would be great, especially since the database tables are populated somewhat statically on the back-end of the SCPs and it doesn't require an STP/SSP (BGP speaker in our lingo) to perform any authentication stuff. Then again, it's certainly got it's share of scalability and resiliency issues as well. Of course, simply having the ability to statically define 100K+ prefix-based policies without my routers blowing chunks would be a really good place to start. -danny > We see a strong interest from both Public and Private carriers > building Next Generation IP networks - who want to have the > same kind of secure networks they have today with their SS7 > Circuit Switch Networks. > > We will actively participate in any IETF work in this area > and will support Interoperability with other Router vendors > to help move from a draft status to a standard. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA05074 for ; Thu, 27 Jan 2000 12:38:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7D1C95E00F; Thu, 27 Jan 2000 12:29:31 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 62D195DEBC; Thu, 27 Jan 2000 12:27:07 -0500 (EST) Received: from tristero.cryptocourier.com (black-3.dsl.speakeasy.net [216.231.56.189]) by segue.merit.edu (Postfix) with SMTP id 8EC1A5E0C7 for ; Thu, 27 Jan 2000 12:25:05 -0500 (EST) Received: (qmail 23488 invoked from network); 27 Jan 2000 17:21:20 -0000 Received: from ae.layer8.net (HELO ae) (192.168.69.10) by tristero.cryptocourier.com with SMTP; 27 Jan 2000 17:21:20 -0000 Message-ID: <004e01bf68ea$743c2d40$0a45a8c0@layer8.net> Reply-To: "Benjamin Black" From: "Benjamin Black" To: "Susan Hares" , References: Subject: Re: Secure BGP -- Internet Drafts Date: Thu, 27 Jan 2000 09:17:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-idr@merit.edu Precedence: bulk My initial impression is that these drafts provide definite benefits, but I am concerned by their potential computational demands and difficulty in deploying the supporting infrastructure (specifically certificate servers). You reference a paper to be published next month which specifically addresses the performance issue. Can this be provided to the group? Ben > > Here are a few drafts on BBN's work on Secure BGP. > Should these drafts become IDR working group drafts? > Please send comments to the list. > > > Sue Hares > > -------------- > > Message-Id: > Date: Fri, 29 Oct 1999 00:14:15 -0400 > To: idr@merit.edu > From: Karen Seo > Subject: Secure BGP -- Internet Drafts > Cc: sbgp@po2.bbn.com > > Hello, > > Over the past year, we (Charlie Lynn and Luis Sanchez) have made > presentations on our Secure BGP (S-BGP) work at several IDR WG sessions. We > would now like to submit two internet drafts on Secure BGP (see below) to > the IDR working group for review/feedback and consideration for adoption > as IDR working group documents. We have sent both to the IETF secretariat > and also put copies at our web site: > http://www.ir.bbn.com/projects/sbgp/ > > It should be noted that we have prepared these (individual submission) > I-Ds, based on our experience with a prototype implementation and initial > testing, including some performance measurements. Thus, we feel that the > design is now sufficiently mature to warrant requesting that the IDR WG > formally consider adopting it as the basis for a work item, oriented > towards providing high quality security for BGP. > > Please let us know if you have questions/comments. Thank you, > Karen > > 1. Secure BGP (S-BGP) -- Charles Lynn, Joanne Mikkelson, Karen Seo, > draft-clynn-s-bgp-protocol-00.txt, October 1999. > > Abstract > > The Border Gateway Protocol (BGP), which is used to distribute routing > information between autonomous systems (ASes), is a critical component > of the Internet's routing infrastructure. It is highly vulnerable to a > variety of malicious attacks both in theory and in practice, due to > the lack of a scalable means of verifying the authenticity and > legitimacy of BGP control traffic. This document is a protocol > specification for Secure BGP (S-BGP), an extension to BGP-4. S-BGP > adheres to the principle of least privilege and uses countermeasures > that create an authentication and authorization system that addresses > most of the security problems associated with BGP. To facilitate > adoption and deployment, S-BGP is designed to minimize the overhead > (processing, bandwidth, storage) added by its > > 2. X.509 Extensions for Authorization of IP Addresses, AS Numbers, and > Routers within an AS -- Charles Lynn, draft-clynn-bgp-x509-auth-01.txt, > October 1999. > > Abstract > > This document defines three X.509 v3 Certificate Extensions. The > first binds a list of IP Address blocks to the public key of the > subject of a certificate. The second binds a list of Autonomous > System Numbers to the public key of the subject of a certificate. > The third binds a BGP Router Identifier and an Autonomous System > Number to the public key of the subject of a certificate. Third > parties, e.g., BGP routers, may use these certificates to verify > that the holder of the private key corresponding to the public > key in the certificate has been properly authorized to use > resources specified in the certificate extension. > > > > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA03971 for ; Thu, 27 Jan 2000 11:27:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id D67545DE3F; Thu, 27 Jan 2000 11:25:24 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9DDD15DFAD; Thu, 27 Jan 2000 11:25:14 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 0D7E85DFAD for ; Thu, 27 Jan 2000 11:23:48 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12DrMx-0008j1-00; Thu, 27 Jan 2000 08:02:03 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Hank Zannini Cc: Subject: Re: Secure BGP -- Internet Drafts References: <200001271323.IAA13305@mlsrv1.avici.com> Message-Id: Date: Thu, 27 Jan 2000 08:02:03 -0800 Sender: owner-idr@merit.edu Precedence: bulk > I [We - Avici] certainly support the ietf is made up of individual experts, not companies. randy Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA03933 for ; Thu, 27 Jan 2000 11:26:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id D0B555DFAB; Thu, 27 Jan 2000 11:09:44 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0C8C05DFB1; Thu, 27 Jan 2000 11:08:56 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by segue.merit.edu (Postfix) with ESMTP id 41E0A5DFAE for ; Thu, 27 Jan 2000 11:08:37 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by mail.nyp.ans.net (8.9.3/8.9.3) with ESMTP id KAA25119 for ; Thu, 27 Jan 2000 10:45:29 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (VWALL-IN-motgate 2.0) with ESMTP id IAA20305 for ; Thu, 27 Jan 2000 08:45:28 -0700 (MST)] Received: [from s-il02-d.comm.mot.com (s-il02-d.comm.mot.com [145.1.204.14]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id IAA19993 for ; Thu, 27 Jan 2000 08:45:26 -0700 (MST)] Received: by s-il02-d.comm.mot.com with Internet Mail Service (5.5.2650.21) id ; Thu, 27 Jan 2000 09:45:26 -0600 Message-ID: <0F762B016151D2118F8900805FA795AF0365EB8D@s-il02-n.comm.mot.com> From: Lewis Adam-CAL022 To: BGP mailing list Subject: Looking for Convergence Date: Thu, 27 Jan 2000 09:45:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk Can anybody recommend a paper that deals with Convergence and BGP? I'm trying to determine the convergence time for a particual network architecture. Thanks! ------ Adam Lewis Avanced Technology & Strategy Global Technologies Developement Group 1301 East Algonquin Road, Schuamburg, Illinois 60196 Telephone: (847) 576-8489 Fax: (847) 576-9018 Email: adam.lewis@motorola.com Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA01534 for ; Thu, 27 Jan 2000 09:04:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 794C95DEED; Thu, 27 Jan 2000 09:03:07 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 683895DE17; Thu, 27 Jan 2000 08:59:06 -0500 (EST) Received: from mlsrv1.avici.com (unknown [208.246.215.9]) by segue.merit.edu (Postfix) with ESMTP id CFED35DDF9 for ; Thu, 27 Jan 2000 08:50:27 -0500 (EST) Received: from [216.192.214.43] (atl-qbu-zpm-vty43.as.wcom.net [216.192.214.43]) by mlsrv1.avici.com (8.8.5/8.8.4) with SMTP id IAA13305 for ; Thu, 27 Jan 2000 08:23:59 -0500 (EST) Message-Id: <200001271323.IAA13305@mlsrv1.avici.com> Subject: Re: Secure BGP -- Internet Drafts Date: Thu, 27 Jan 2000 08:24:39 -0500 x-sender: hank@mailhost.avici.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Hank Zannini To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-idr@merit.edu Precedence: bulk > >Here are a few drafts on BBN's work on Secure BGP. >Should these drafts become IDR working group drafts? >Please send comments to the list. > > >Sue Hares > Hi Sue: I [We - Avici] certainly support adding the drafts submitted by BBN for a Secure BGP. We see a strong interest from both Public and Private carriers building Next Generation IP networks - who want to have the same kind of secure networks they have today with their SS7 Circuit Switch Networks. We will actively participate in any IETF work in this area and will support Interoperability with other Router vendors to help move from a draft status to a standard. Cheers, Hank Experience is that marvelous thing that enables you to recognize a mistake when you make it again *********************************************************** * Hank Zannini - FOUNDER E-mail Hank@Avici.com * * Vice President Business Dev. MAIN +1-978-964-2000 * * Avici Systems, Inc. VOICE +1-978-964-2222 * * 101 Billerica Ave Hank's Follow Me +1-603-890-5539 * * Building # 6 * * N. Billerica, MA 01862 Fax +1-978-964-2100 * * * * http://www.Avici.com * *********************************************************** Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA20629 for ; Wed, 26 Jan 2000 12:00:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 307675DDDB; Wed, 26 Jan 2000 11:59:29 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DF2905DDE6; Wed, 26 Jan 2000 11:59:28 -0500 (EST) Received: from backin5.merit.edu (backin5.merit.edu [198.108.60.28]) by segue.merit.edu (Postfix) with ESMTP id 409345DDDB for ; Wed, 26 Jan 2000 11:59:27 -0500 (EST) Received: by backin5.merit.edu (Postfix) id D6DFCA9512; Wed, 26 Jan 2000 11:59:27 -0500 (EST) Received: by backin5.merit.edu (Postfix, from userid 8049) id D19A2A9514; Wed, 26 Jan 2000 11:59:25 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by backin5.merit.edu (Postfix) with ESMTP id 3510FA6A04; Wed, 26 Jan 2000 11:59:25 -0500 (EST) Date: Wed, 26 Jan 2000 11:59:25 -0500 (EST) From: Susan Hares To: idr@merit.edu Cc: kseo@bbn.com, sbgp@po2.bbn.com Subject: Secure BGP -- Internet Drafts Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk Here are a few drafts on BBN's work on Secure BGP. Should these drafts become IDR working group drafts? Please send comments to the list. Sue Hares -------------- Message-Id: Date: Fri, 29 Oct 1999 00:14:15 -0400 To: idr@merit.edu From: Karen Seo Subject: Secure BGP -- Internet Drafts Cc: sbgp@po2.bbn.com Hello, Over the past year, we (Charlie Lynn and Luis Sanchez) have made presentations on our Secure BGP (S-BGP) work at several IDR WG sessions. We would now like to submit two internet drafts on Secure BGP (see below) to the IDR working group for review/feedback and consideration for adoption as IDR working group documents. We have sent both to the IETF secretariat and also put copies at our web site: http://www.ir.bbn.com/projects/sbgp/ It should be noted that we have prepared these (individual submission) I-Ds, based on our experience with a prototype implementation and initial testing, including some performance measurements. Thus, we feel that the design is now sufficiently mature to warrant requesting that the IDR WG formally consider adopting it as the basis for a work item, oriented towards providing high quality security for BGP. Please let us know if you have questions/comments. Thank you, Karen 1. Secure BGP (S-BGP) -- Charles Lynn, Joanne Mikkelson, Karen Seo, draft-clynn-s-bgp-protocol-00.txt, October 1999. Abstract The Border Gateway Protocol (BGP), which is used to distribute routing information between autonomous systems (ASes), is a critical component of the Internet's routing infrastructure. It is highly vulnerable to a variety of malicious attacks both in theory and in practice, due to the lack of a scalable means of verifying the authenticity and legitimacy of BGP control traffic. This document is a protocol specification for Secure BGP (S-BGP), an extension to BGP-4. S-BGP adheres to the principle of least privilege and uses countermeasures that create an authentication and authorization system that addresses most of the security problems associated with BGP. To facilitate adoption and deployment, S-BGP is designed to minimize the overhead (processing, bandwidth, storage) added by its 2. X.509 Extensions for Authorization of IP Addresses, AS Numbers, and Routers within an AS -- Charles Lynn, draft-clynn-bgp-x509-auth-01.txt, October 1999. Abstract This document defines three X.509 v3 Certificate Extensions. The first binds a list of IP Address blocks to the public key of the subject of a certificate. The second binds a list of Autonomous System Numbers to the public key of the subject of a certificate. The third binds a BGP Router Identifier and an Autonomous System Number to the public key of the subject of a certificate. Third parties, e.g., BGP routers, may use these certificates to verify that the holder of the private key corresponding to the public key in the certificate has been properly authorized to use resources specified in the certificate extension. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA01392 for ; Mon, 24 Jan 2000 15:03:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id AE1AB5DE89; Mon, 24 Jan 2000 15:02:19 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E30535DE7B; Mon, 24 Jan 2000 15:02:14 -0500 (EST) Received: from tristero.cryptocourier.com (black-3.dsl.speakeasy.net [216.231.56.189]) by segue.merit.edu (Postfix) with SMTP id 6B0545DE7D for ; Mon, 24 Jan 2000 15:01:12 -0500 (EST) Received: (qmail 17382 invoked from network); 24 Jan 2000 20:01:58 -0000 Received: from ae.layer8.net (HELO ae) (192.168.69.10) by tristero.cryptocourier.com with SMTP; 24 Jan 2000 20:01:58 -0000 Message-ID: <00ab01bf66a5$658debe0$0a45a8c0@layer8.net> Reply-To: "Benjamin Black" From: "Benjamin Black" To: "Sandy Murphy" , References: <200001241715.MAA10325@clipper.gw.tislabs.com> Subject: Re: draft-murphy-bgp-secr-03.txt Date: Mon, 24 Jan 2000 11:58:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-idr@merit.edu Precedence: bulk Responses in-line, but overall the point to take away is: cover current best practice for mitigating the vulnerabilities you describe or restrict your discussion to a listing of the vulnerabilities without proposed solutions. Ignoring current practice while presenting a partial specification of a system with no deployment is just not useful to those trying to implement policy to better secure their networks. > >I am a bit confused as to why no mention is made of > >several security mechanisms already in use by most ISPs: AS_PATH filtering, > >prefix filtering, NEXT_HOP filtering, etc. Current BGP implementation offer > >a wealth of options for constraining information exchanged between BGP > >peers. > > The mechanisms you suggest are operational configurations of BGP or of > routers. This draft is an analysis of the protoctol, as specified in > the spec. It cannot address operational aspects of the use of BGP, > because those vary widely from vendor to vendor and ISP to ISP. > The common practice for implementing policies to mitigate the risks you describe can certainly be covered. There are just not that many variants in widespread use, and presenting them would certainly be of more use to network operators than changes to the protocol which no vendor has adopted. > If you think that the implementation configuration options you mention > avoid the vulnerabilities of the prototcol, then you should speak up > to have these mechanisms standardized and mandated as part of the > protocol. The mechanisms I describe do not belong in the protocol. They are simply common practice and common practice is often documented in an RFC other than the one describing the original protocol. This is why the TCP protocol is described in one RFC, but all sorts of implementation mistakes and suggestions are described in another set of RFCs. > No, I'm not being facetious. I've not seen specs of these > mechanisms so I can't say for sure whether they do or do not eliminate > the vulnerability. But it's unlikely that they can eliminate the > potential for widespread disruptions if they are vendor specific and > not everywhere employed. > It is, however, likely that the vast majority (greater than 95%) of the deployed implementations *do* support the mechanisms to which I refer. I'm suggesting that instead of focusing on issues such as forging the AS path (a problem for which you propose a solution), you might present current common practice for solving the bulk of the problems you describe. Filtering based on next-hop is common at exchange points, for example. My point is that you should either explain security vulnerabilities and nothing else, or you present vulnerabilities along with current or proposed solutions for each (assuming one exists). > >The term "non-BGP peer" is extremely ambiguous. > > OK, I see your point. I meant "something other than a BGP peer". Could > you make a suggestion of a non-ambiguous term? > > >The proposed AS signing scheme would benefit greatly from an estimate of the > >computational resources required to verify the signatures of 65000 paths, > >each consisting of perhaps 4 or 5 ASes. > > The only answer possible is that the time it would take to verify the > signatures is 65000*(4or5)*TimeForOneSignatureVerification. To give a > better answer requires knowledge of the signature algorithm, the > implementation, the platform, and the key size. At least. > > The SBGP project has actually done a real-life implementation of an > AS_PATH signing scheme. You could look at draft-clynn-s-bgp-protocol-00.txt > if you wanted more information about their approach. I think they've > published some papers describing their experience, but I'm not sure where. > > >Section 3.5.1 outlines exactly how the proposed signature scheme fails for > >aggregation, yet offers no solution to the problem which provides any > >measure of security. As is clearly stated, either a significant increase in > >space for routing information is required to handle key and plaintext > >information for every component of an aggregate (meaning a router is > >carrying as much information as without aggregation) or aggregators are > >permitted to reset the signing process, completely invalidating any security > >benefits. > > The purpose of this draft is to list various possible protections and > describe the assurance derived from each. Agreed. This is why I pointed out the numerous *deployed* solutions for the problems presented and took a dim view regarding a proposed AS path signature scheme with no deployment. > I do not know of any > protection that I or anyone else have proposed that treat aggregation > points with any better results. Since an aggregated AS_PATH does not > make a definite statement ("the route to this NLRI transits some or > none of the AS's in this AS_PATH in no particular order"), it is > hard for me to see what sort of assurance it is possible to give > about that statement. > > Again, the SBGP folk have implemented an AS_PATH signing scheme and > they have taken the approach of including all the signature > information for the AS_PATHS that feed into the aggregate into the > aggregated UPDATE. Essentially, they are providing enough information > to remove the vagueness in the aggregated statement. If you wish to > know more details of the space aspects of their approach, you should > discuss that with them directly. > Perhaps, but they are not the ones presenting a draft to the idr working group. You should either provide a complete specification of the signature scheme or remove it. > >An EBGP neighbor must prepend its own AS onto the path. There is no > >legitimate reason for not performing this action as it is fundamental to > >loop avoidance. > > That is how I read the spec, but conversations in the group and in the > list seemed to suggest otherwise. I've brought this question up in > working group meetings with interesting results - lots of people at > the microphone claiming that the AS must be prepended, lots of people > at the microphone claiming that they frequently do not prepend. > They may not prepend *additional* copies of their AS, but they are *definitely* prepending at least one copy of their AS onto the path. > Note that if there are many people who do not prepend their AS, then There are none. > current implementations must not be viewing an AS_PATH that does not > start with the AS of the neighbor as an error. So arbitrary AS's are > accepted. That's a vulnerability. One might claim that those non-prepending > people are living in sin and should mend their ways and the best way > to make sure they do is to make it part of protocol compliance that > the initial AS must be checked. But given the number of people who > claim they do not prepend for their own reasons, mandating that check > of the first AS should be discussed on the mailing list. > There is no need for a mandate. The protocol is quite clear on the subject: b) When a given BGP speaker advertises the route to a BGP speaker located in a neighboring autonomous system, then the advertising speaker shall update the AS_PATH attribute as follows: 1) if the first path segment of the AS_PATH is of type AS_SEQUENCE, the local system shall prepend its own AS number as the last element of the sequence (put it in the leftmost position). 2) if the first path segment of the AS_PATH is of type AS_SET, the local system shall prepend a new path segment of type AS_SEQUENCE to the AS_PATH, including its own AS number in that segment. There is simply no ambiguity here. If there is concern that malicious peers may manipulate the AS path, AS path filtering is simple enough and extremely common in practice. This is the sort of thing that *should* be discussed in a draft regarding security. > As for your comments about an origin of INCOMPLETE and the NEXT_HOP AS > discussion, I'm not sure if you are saying that the vulnerability is > more or less than I've stated, so in those cases I'm going to have to > go read the section and your response with more care. > My comment regarding the ORIGIN attribute was that the vulnerability is more (however slightly) than what you believed. My comments regarding the NEXT_HOP attribute were explaining how such risks are mitigated in practice. Ben Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA00560 for ; Mon, 24 Jan 2000 14:28:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 22EF5604D6; Mon, 24 Jan 2000 14:12:13 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A3AD65E41F; Mon, 24 Jan 2000 13:32:14 -0500 (EST) Received: from sentry (sentry.gw.tislabs.com [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id 057835E41D for ; Mon, 24 Jan 2000 12:18:59 -0500 (EST) Received: by sentry; id MAA27096; Mon, 24 Jan 2000 12:20:00 -0500 (EST) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma027079; Mon, 24 Jan 00 12:19:39 -0500 Received: (from sandy@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id MAA10325; Mon, 24 Jan 2000 12:15:28 -0500 (EST) Date: Mon, 24 Jan 2000 12:15:28 -0500 (EST) From: Sandy Murphy Message-Id: <200001241715.MAA10325@clipper.gw.tislabs.com> To: idr@merit.edu Subject: Re: draft-murphy-bgp-secr-03.txt Cc: sandy@tislabs.com Sender: owner-idr@merit.edu Precedence: bulk >I have numerous concerns regarding the information in this draft, some of >which are below. Well, I'll try to address the ones you have included. Will you be posting the others to the list any time soon? Some of these I can answer off the top of my head. Others I'll have to go back and re-read the section mentioned - the context provided isn't enough for me to see the point - but that will be later this week and I wanted to answer those I could immediately. >I am a bit confused as to why no mention is made of >several security mechanisms already in use by most ISPs: AS_PATH filtering, >prefix filtering, NEXT_HOP filtering, etc. Current BGP implementation offer >a wealth of options for constraining information exchanged between BGP >peers. The mechanisms you suggest are operational configurations of BGP or of routers. This draft is an analysis of the protoctol, as specified in the spec. It cannot address operational aspects of the use of BGP, because those vary widely from vendor to vendor and ISP to ISP. If you think that the implementation configuration options you mention avoid the vulnerabilities of the prototcol, then you should speak up to have these mechanisms standardized and mandated as part of the protocol. No, I'm not being facetious. I've not seen specs of these mechanisms so I can't say for sure whether they do or do not eliminate the vulnerability. But it's unlikely that they can eliminate the potential for widespread disruptions if they are vendor specific and not everywhere employed. >The term "non-BGP peer" is extremely ambiguous. OK, I see your point. I meant "something other than a BGP peer". Could you make a suggestion of a non-ambiguous term? >The proposed AS signing scheme would benefit greatly from an estimate of the >computational resources required to verify the signatures of 65000 paths, >each consisting of perhaps 4 or 5 ASes. The only answer possible is that the time it would take to verify the signatures is 65000*(4or5)*TimeForOneSignatureVerification. To give a better answer requires knowledge of the signature algorithm, the implementation, the platform, and the key size. At least. The SBGP project has actually done a real-life implementation of an AS_PATH signing scheme. You could look at draft-clynn-s-bgp-protocol-00.txt if you wanted more information about their approach. I think they've published some papers describing their experience, but I'm not sure where. >Section 3.5.1 outlines exactly how the proposed signature scheme fails for >aggregation, yet offers no solution to the problem which provides any >measure of security. As is clearly stated, either a significant increase in >space for routing information is required to handle key and plaintext >information for every component of an aggregate (meaning a router is >carrying as much information as without aggregation) or aggregators are >permitted to reset the signing process, completely invalidating any security >benefits. The purpose of this draft is to list various possible protections and describe the assurance derived from each. I do not know of any protection that I or anyone else have proposed that treat aggregation points with any better results. Since an aggregated AS_PATH does not make a definite statement ("the route to this NLRI transits some or none of the AS's in this AS_PATH in no particular order"), it is hard for me to see what sort of assurance it is possible to give about that statement. Again, the SBGP folk have implemented an AS_PATH signing scheme and they have taken the approach of including all the signature information for the AS_PATHS that feed into the aggregate into the aggregated UPDATE. Essentially, they are providing enough information to remove the vagueness in the aggregated statement. If you wish to know more details of the space aspects of their approach, you should discuss that with them directly. >An EBGP neighbor must prepend its own AS onto the path. There is no >legitimate reason for not performing this action as it is fundamental to >loop avoidance. That is how I read the spec, but conversations in the group and in the list seemed to suggest otherwise. I've brought this question up in working group meetings with interesting results - lots of people at the microphone claiming that the AS must be prepended, lots of people at the microphone claiming that they frequently do not prepend. Note that if there are many people who do not prepend their AS, then current implementations must not be viewing an AS_PATH that does not start with the AS of the neighbor as an error. So arbitrary AS's are accepted. That's a vulnerability. One might claim that those non-prepending people are living in sin and should mend their ways and the best way to make sure they do is to make it part of protocol compliance that the initial AS must be checked. But given the number of people who claim they do not prepend for their own reasons, mandating that check of the first AS should be discussed on the mailing list. As for your comments about an origin of INCOMPLETE and the NEXT_HOP AS discussion, I'm not sure if you are saying that the vulnerability is more or less than I've stated, so in those cases I'm going to have to go read the section and your response with more care. --Sandy Murphy Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA11332 for ; Sat, 22 Jan 2000 02:41:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1BC595DDA8; Sat, 22 Jan 2000 02:41:25 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CE8775DD8C; Sat, 22 Jan 2000 02:41:24 -0500 (EST) Received: from tristero.cryptocourier.com (black-3.dsl.speakeasy.net [216.231.56.189]) by segue.merit.edu (Postfix) with SMTP id D01365DDA8 for ; Sat, 22 Jan 2000 02:41:22 -0500 (EST) Received: (qmail 13699 invoked from network); 22 Jan 2000 07:42:22 -0000 Received: from ae.layer8.net (HELO ae) (192.168.69.10) by tristero.cryptocourier.com with SMTP; 22 Jan 2000 07:42:22 -0000 Message-ID: <008501bf64ab$dda31160$0a45a8c0@layer8.net> Reply-To: "Benjamin Black" From: "Benjamin Black" To: , "Yakov Rekhter" References: <200001211607.IAA25196@omega.cisco.com> Subject: Re: draft-murphy-bgp-secr-03.txt Date: Fri, 21 Jan 2000 23:39:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-idr@merit.edu Precedence: bulk I have numerous concerns regarding the information in this draft, some of which are below. I am a bit confused as to why no mention is made of several security mechanisms already in use by most ISPs: AS_PATH filtering, prefix filtering, NEXT_HOP filtering, etc. Current BGP implementation offer a wealth of options for constraining information exchanged between BGP peers. The draft proposes solutions which would require significant changes to BGP implementations as well as significant computational resources, while completely ignoring common practice and existing policy mechanisms. The term "non-BGP peer" is extremely ambiguous. Does it refer to a peer which is not speaking BGP or an entity which is not a peer at all? A clear definition, if not a terminology change, would greatly improve this confusion. The proposed AS signing scheme would benefit greatly from an estimate of the computational resources required to verify the signatures of 65000 paths, each consisting of perhaps 4 or 5 ASes. What about a router which must sign 65000 routes for each of its peers? This seems rather far outside the realm of possibility for a typical backbone router within a reasonable amount of time. Section 3.5.1 outlines exactly how the proposed signature scheme fails for aggregation, yet offers no solution to the problem which provides any measure of security. As is clearly stated, either a significant increase in space for routing information is required to handle key and plaintext information for every component of an aggregate (meaning a router is carrying as much information as without aggregation) or aggregators are permitted to reset the signing process, completely invalidating any security benefits. This is a fairly substantial shortcoming, even if the computational demands were met. >From section A4.3: In regards to ORIGIN (these sections should really have subsection numbers): This field indicates whether the information was learned from IGP or EGP information. If the route is used in inter-AS multicast routing, a values of INCOMPLETE may be used. This field is not used in making routing decisions, so there are no vulnerabilities arising from this field, either from BGP peers or non-BGP peers. An origin of INCOMPLETE is perfectly valid for unicast routes. In addition, although not specified in RFC1771, origin information is certainly used for tie-breaking in the vast majority of deployed BGP speakers. In regards to AS_PATH: If there are legitimate situations in which a BGP speaker could pass an AS_PATH to a neighbor without putting its own AS at the head of the AS_PATH, then there is no way for implementations to detect totally bogus AS_PATHs. An EBGP neighbor must prepend its own AS onto the path. There is no legitimate reason for not performing this action as it is fundamental to loop avoidance. In regards to NEXT_HOP: It is unclear whether this would also require the advertising BGP speaker to construct an AS_PATH mentioning the NEXT_HOP inter-AS peer's AS. What is unclear? There is no requirement that a next hop IP be part of the AS of the peer announcing routes with that next hop. A peer is just as free to set next hop to whatever they like as their peer is to drop routes without the expected next hop. ----- Original Message ----- From: Yakov Rekhter To: Sent: Friday, January 21, 2000 8:07 AM Subject: draft-murphy-bgp-secr-03.txt > Folks, > > I'd like to get your opinion on accepting draft-murphy-bgp-secr-03.txt > as an IDR WG document with the ultimate goal of publishing it as > an Informational RFC. Please comment on this within the next 2 weeks. > > Yakov. > > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA02764 for ; Fri, 21 Jan 2000 16:15:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8D0D75DDBC; Fri, 21 Jan 2000 11:08:07 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4E34D5DDBD; Fri, 21 Jan 2000 11:08:07 -0500 (EST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by segue.merit.edu (Postfix) with ESMTP id 26FA75DDBC for ; Fri, 21 Jan 2000 11:08:01 -0500 (EST) Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA25196 for ; Fri, 21 Jan 2000 08:07:58 -0800 (PST) Message-Id: <200001211607.IAA25196@omega.cisco.com> To: idr@merit.edu Subject: draft-murphy-bgp-secr-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25193.948470877.1@cisco.com> Date: Fri, 21 Jan 2000 08:07:57 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, I'd like to get your opinion on accepting draft-murphy-bgp-secr-03.txt as an IDR WG document with the ultimate goal of publishing it as an Informational RFC. Please comment on this within the next 2 weeks. Yakov. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA02767 for ; Fri, 21 Jan 2000 16:15:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 47F205DDBD; Fri, 21 Jan 2000 11:18:53 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E76555DDD8; Fri, 21 Jan 2000 11:18:52 -0500 (EST) Received: from roam.psg.com (mg136-131.ricochet.net [204.179.136.131]) by segue.merit.edu (Postfix) with ESMTP id 267A05DDBD for ; Fri, 21 Jan 2000 11:18:41 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12Bgld-00051G-00; Fri, 21 Jan 2000 08:18:33 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Yakov Rekhter Cc: idr@merit.edu Subject: Re: draft-murphy-bgp-secr-03.txt References: <200001211607.IAA25196@omega.cisco.com> Message-Id: Date: Fri, 21 Jan 2000 08:18:33 -0800 Sender: owner-idr@merit.edu Precedence: bulk > I'd like to get your opinion on accepting draft-murphy-bgp-secr-03.txt > as an IDR WG document with the ultimate goal of publishing it as > an Informational RFC. Please comment on this within the next 2 weeks. please randy Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA17765 for ; Thu, 13 Jan 2000 07:48:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id AAC3A5DDCE; Thu, 13 Jan 2000 07:48:36 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8360C5DDD0; Thu, 13 Jan 2000 07:48:35 -0500 (EST) Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17]) by segue.merit.edu (Postfix) with ESMTP id A1A765DDCE for ; Thu, 13 Jan 2000 07:48:28 -0500 (EST) Received: from oleane (dyn-1-1-028.Vin.dialup.oleane.fr [195.25.4.28]) by smtp2.cluster.oleane.net with SMTP id NAA35249; Thu, 13 Jan 2000 13:48:12 +0100 (CET) Message-ID: <001001bf5dc4$19ddc240$0401a8c0@oleane.com> From: "Peter Lewis" To: Subject: MPLS Forum Date: Thu, 13 Jan 2000 13:45:31 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01BF5DCC.758AB780" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-idr@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000D_01BF5DCC.758AB780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The MPLS Forum will stand in Paris next 7-10 March. Reports from real deployments, standard progress issues, technical propositions, debate: building the next IP architecture. Get details at: www.upperside.fr/mplsforum.htm ------=_NextPart_000_000D_01BF5DCC.758AB780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The MPLS = Forum will stand=20 in Paris next 7-10 March. Reports from real
deployments, standard = progress=20 issues, technical propositions, debate:
building the next IP=20 architecture.
Get details at:
www.upperside.fr/mplsforum= .htm
 
 
------=_NextPart_000_000D_01BF5DCC.758AB780-- Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA17461 for ; Tue, 11 Jan 2000 07:14:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 95A685DDC3; Tue, 11 Jan 2000 07:14:11 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4B1F35DE15; Tue, 11 Jan 2000 07:14:11 -0500 (EST) Received: from smtp1.cluster.oleane.net (smtp1.cluster.oleane.net [195.25.12.16]) by segue.merit.edu (Postfix) with ESMTP id D58435DDC3 for ; Tue, 11 Jan 2000 07:14:08 -0500 (EST) Received: from oleane (dyn-1-1-205.Vin.dialup.oleane.fr [195.25.4.205]) by smtp1.cluster.oleane.net with SMTP id NAA45601; Tue, 11 Jan 2000 13:13:54 +0100 (CET) Message-ID: <001201bf5c2c$fa913540$0401a8c0@oleane.com> From: "Peter Lewis" To: Subject: Cellular Internet Call for Paper Date: Tue, 11 Jan 2000 13:11:18 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01BF5C35.58C52380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-idr@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000F_01BF5C35.58C52380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cellular Internet: The Micro-Mobility Approach The micro-mobility concept is the most recent and promising approach = proposed to add mobility to the Internet and packet data services to = third generation cellular systems. =20 A CFP is available at:=20 http://www.upperside.fr/baipcn.htm ------=_NextPart_000_000F_01BF5C35.58C52380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Cellular Internet: The = Micro-Mobility=20 Approach

The micro-mobility concept is the most recent and = promising=20 approach proposed to add mobility to the Internet and packet data = services to=20 third generation cellular systems.
 
A CFP is available at:=20
http://www.upperside.fr/baipc= n.htm
------=_NextPart_000_000F_01BF5C35.58C52380--