Re: BGP to doom us all
From: Stephen Kent <[EMAIL PROTECTED]> Subject: Re: BGP to doom us all Date: Wed, 2 Apr 2003 18:15:05 -0500 Folks, I was not subscribed to the workshop list when Randy forwarded this message at the beginning of last month. However, I would like to respond to the issues raised in the text. Steve > From: Iljitsch van Beijnum <[EMAIL PROTECTED]> > To: Avi Freedman <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Subject: Re: BGP to doom us all > Date: Sat, 1 Mar 2003 21:09:14 +0100 (CET) > > > On Sat, 1 Mar 2003, Avi Freedman wrote: > >> Re: S-BGP in particular, I think that the analysis on S-BGP has been... >> limited. Ironic for a security protocol that I haven't seen any >> real analysis of the effect on router CPUs when *under attack*. I >> am not saying "oh, the authentication will drive things way too high". >> I'm just saying that we don't know because the simulations have used >> very conservative parameters. > > My two cents: > > By looking at the packet formats I estimate that the memory requirements > for S-BGP are about 4 times those of regular BGP (mind you - just the > BGP table, RIB and FIB remain the same). This gets us pretty close to > common 32-bit CPU address space limits. Whie it is true that the size of UPDATE messages grows considerably under S-BGP, the amount of extra space needed in RIBs is a function of the implementation approach that one adopts, and so it is hard to translate the space occupied by RAs in an UPDATE into the extra RIB space that will be used. Obviously, if a router has many peers, then the increase in the Adj and Loc RIB sizes will be magnified, and no fanout number was provided in the comment above. But it does not seem likely that we would really be close to 32-bit address space limits based on our analysis and some (limited) implementation experience. > For receiving updates: you are expected to check the validity of each > hop in each AS path in the global routing table using a public key > signature verification. A Pentium-class CPU can do a few thousand of > those per second, so that adds several minutes of pure CPU time to the > initialization of each full feed. This means crypto hardware. In the papers we published, we explicitly noted that initialization could be a problem, and suggested that initialization after a crash would benefit from a restoral strategy (using NV storage for the Loc RIBs) or from a deferred evaluation strategy. We have thought more about this latter strategy, and a variant of it also is attractive for any router with many peers. The observation is that when you have many peers, most of the UPDATEs that are received will not result in generation of UPDATEs, and thus one need not evaluate the signatures, since they didn't influence operation (i.e., didn't result in the generation of UPDATEs). This is true both in steady state operation as well as during initialization. Thus one could mark each Adj RIB entry to indicate whether it had been verified, or not. If the router is too busy to verify an UPDATE, then so long as that UPDATE does not change the notion of best route for the prefixes it contains, one can defer (perhaps forever) the signature verification process. (We do preform other, quick checks to weed out bad UPADTEs upon receipt.) Using the strategy, we anticipate that one can significantly reduce the number of signature validation operations that need to be performed, with proportionally greater savings at routers with the most peers. Still, we do think that use of crypto hardware is desirable in the long run, since it allows for better protection of the private key used by a router, and it offers greater capacity to deal with floods of UPDATEs during worst case scenarios. If routers need to be equipped with additional memory anyway, then making provision for a crypto chip would be a reasonable update to a processor board when the memory size changes were made. Modern crypto chips are capable of very high (10's of thousands/second) signature processing rates, but one must pay close attention to the fine print, since there most of the figures do not include the time to load a new signature key into the chip. > For sending updates: you must include the identity of the receiver in > each update (and then sign the update, unless I remember incorrectly). > That means sending out updates to a large number of peers (such as on a > public internet exchange) becomes a rather expensive operation, even > discounting the crypto. I'm not sure why this is a "rather expensive operation, even discounting the crypto." Certainly the bigger UPDATEs take up more TCP queue space, and maybe there is some concern over the need to generate a distinct UPDATE per peer. However, there is a provision to place more than one next hop AS # i
Re: Who uses RADB? [was BGP to doom us all]
> You forgot the other one - expense. AFAIK all of the registries have fees > or require you to be a customer. If there is no operational value for me > why would I want to spend the money? I realize most of you work for > companies that consider a million dollars chump change but that is not the > case everywhere. If you can give me a convincing reason to register my > routes in a RADB I will - but at this point I have yet to see it. There is at least one free best-effort IRR. Also, as you point out, there are several IRRs which permit customers to register for free. RIPE permits (even encourages, I believe) its members to register in its db. ARIN may do the same, as I see they have a db.
Re: Who uses RADB? [was BGP to doom us all]
Mark Radabaugh <[EMAIL PROTECTED]> writes: [...] >You forgot the other one - expense. AFAIK all of the registries have fees >or require you to be a customer. If there is no operational value for me >why would I want to spend the money? I realize most of you work for >companies that consider a million dollars chump change but that is not the >case everywhere. If you can give me a convincing reason to register my >routes in a RADB I will - but at this point I have yet to see it. FYI, the RIPE Database implements RPSL and is free to use. http://www.ripe.net/ripencc/pub-services/db/index.html Regards, -- leo vegoda RIPE NCC Registration Services
Re: BGP to doom us all
On 28.02 18:13, Barry Raveendran Greene wrote: > > Now - show me an operational environment on the Internet were this authorization > chain is _working_ today. RIRs and RADB do not count. As you mention before, > those databases and keeping them up to date are a "pulling teeth" exercise. > > ... > > My opinion is that lazy operational practices are the single biggest threat to > the Internet. What's the point of building security and robustness into a system > when people choose not to turn it on? RIRs do count and the infrastructure to set up the chain is there. Address assignment and allocation is a quite formal and well recorded process these days. The address *allocation&assignment* databases are in good shape for about the last 8 years. The fact that they are not in good shape for assignments from "the good old days" is true. But this is being actively worked on and one should not blow it up out of proportion. Deploying technologies like SBGP would of course provide additional incentives to record allocations and assignments and the resulting signing of certs even better. Daniel
Re: BGP to doom us all
On dinsdag, maa 4, 2003, at 10:26 Europe/Amsterdam, [EMAIL PROTECTED] wrote: How would you feel about ARIN being the root of a registry hierarchy that works similar to the DNS? In that case, ARIN would not necessarily hold the route information, they would just be at the top of the search hierarchy just like the root name servers are at the top of the DNS hierarchy. ARIN would authoritatively identify the leaseholder of an address block and give you a pointer to that leaseholder's LDAP server where you could query for whatever info they have available. So how are you going to reach the leaseholder's LDAP server if you're in the middle of checking their prefix to see if it's worthy of being included in your routing table?
Re: BGP to doom us all
> > U it's nice to be able to change routing information in a > > timely fashion without needing intensive therapy afterward. The > > idea isn't inherently bad, but I'd not want the current ARIN > > acting as a route registry. > > How would you feel about ARIN being the root of a registry hierarchy that > works similar to the DNS? In that case, ARIN would not necessarily hold > the route information, they would just be at the top of the search > hierarchy just like the root name servers are at the top of the DNS > hierarchy. ARIN would authoritatively identify the leaseholder of an > address block and give you a pointer to that leaseholder's LDAP server > where you could query for whatever info they have available. This could > include route registry info. > --Michael Dillon I don't know that the other RIRs would be willing to promote ARIN to the position once held by the IANA as the arbitor of all IP address space. That said, why replicate the DNS? --bill
Re: BGP to doom us all
## On 2003-03-04 09:26 - [EMAIL PROTECTED] typed: > > > U it's nice to be able to change routing information in a > > timely fashion without needing intensive therapy afterward. The > > idea isn't inherently bad, but I'd not want the current ARIN > > acting as a route registry. > > How would you feel about ARIN being the root of a registry hierarchy that > works similar to the DNS? I hope you meant IANA as the root of the registry ? ARIN is (just ;-) a RIR just like RIPE or APNIC >> In that case, ARIN would not necessarily hold > the route information, they would just be at the top of the search > hierarchy just like the root name servers are at the top of the DNS > hierarchy. ARIN would authoritatively identify the leaseholder of an > address block and give you a pointer to that leaseholder's LDAP server > where you could query for whatever info they have available. This could > include route registry info. > > --Michael Dillon -- Rafi > > > > >
Re: BGP to doom us all
> U it's nice to be able to change routing information in a > timely fashion without needing intensive therapy afterward. The > idea isn't inherently bad, but I'd not want the current ARIN > acting as a route registry. How would you feel about ARIN being the root of a registry hierarchy that works similar to the DNS? In that case, ARIN would not necessarily hold the route information, they would just be at the top of the search hierarchy just like the root name servers are at the top of the DNS hierarchy. ARIN would authoritatively identify the leaseholder of an address block and give you a pointer to that leaseholder's LDAP server where you could query for whatever info they have available. This could include route registry info. --Michael Dillon
Re: BGP to doom us all
JB> Date: Mon, 3 Mar 2003 09:45:37 -0600 JB> From: Jack Bates JB> Personally, I think ARIN handling routing information is an JB> excellent idea. It has to be separate from SWIP though, as U it's nice to be able to change routing information in a timely fashion without needing intensive therapy afterward. The idea isn't inherently bad, but I'd not want the current ARIN acting as a route registry. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to be blocked.
RE: Who uses RADB? [was BGP to doom us all]
I know when we separated Concert from iMCI we where using the filters on them, and they IMO would have been a peer, but then again Concert sould have been a special case either way. -Jim -Original Message- From: Danny McPherson [mailto:[EMAIL PROTECTED] Sent: Monday, March 03, 2003 11:59 AM To: [EMAIL PROTECTED] Subject: Re: Who uses RADB? [was BGP to doom us all] Yes, at iMCI (we) had our own registry, MCI-RR, but we only used it (in addition to data from the other IRRs) to generate customer prefix filters, not peers. Cable & Wireless still uses the RR, now know as CW-RR. -danny > As I remember and I could be wrong, its been a few years now, when I worked > for iMCI we did and we moved over to C&W we still did.
Re: BGP to doom us all
> For example, take a naive approach: your router crashes. It comes back > up. It receives 130,000 prefixes that it needs to validate. For each > prefix, your router must do an LDAP query. Then take a smarter approach: your router crashes. It comes back up and your network management system (NMS) pushes a special after-the-crash BGP filter set to it. It receives 130,000 prefixes, most of which pass through the filter just fine. The NMS collects the rejects, queries them against an LDAP server asynchronously and builds a better BGP filter set which gets pushed out to the router once the CPU settles down. Yes, this means that some routes take longer to converge at this particular router but that's not a problem because your resilient network architecture has continued to deliver 100% of packets offered in spite of this router crash. And if the router is crashing often then you have bigger problems to solve. I am not suggesting that router vendors should implement any sort of LDAP capability because it will be stuck in the same morass of ancient slow CPUs, not enough absurdly expensive RAM, years-long test and certification process because it runs on the router, and botched feature set because it has to fit in the vendors wide range of router architectures and they will only implement the features that many customers are clamoring for. The alternative is to use modern fast CPUs running on standard systems with lots of cheap RAM to handle these tasks that are peripheral to the job of packet-forwarding. Then use the standard interfaces already on the router (i.e. telnet from a protected server or SNMP) to communicate with this NMS device Your details may vary but this basic architecture works and it allows the NMS to track more closely with commercial off-the-shelf (COTS) hardware and software. Too many people are biased against this approach because of the days when the IBM RS-6000 based routers were replaced with purpose-built boxes from Cisco and Wellfleet (now Nortel). --Michael Dillon
Re: Who uses RADB? [was BGP to doom us all]
Yes, at iMCI (we) had our own registry, MCI-RR, but we only used it (in addition to data from the other IRRs) to generate customer prefix filters, not peers. Cable & Wireless still uses the RR, now know as CW-RR. -danny > As I remember and I could be wrong, its been a few years now, when I worked > for iMCI we did and we moved over to C&W we still did.
RE: Who uses RADB? [was BGP to doom us all]
As I remember and I could be wrong, its been a few years now, when I worked for iMCI we did and we moved over to C&W we still did. -Jim -Original Message- From: Danny McPherson [mailto:[EMAIL PROTECTED] Sent: Saturday, March 01, 2003 10:48 AM To: [EMAIL PROTECTED] Subject: Re: Who uses RADB? [was BGP to doom us all] > > > Who actually uses RADB to build filters other than Verio? While my > > experience with other providers is limited Verio is the only one (of the > > ones we have used) who used RADB entries for BGP peers. > > Level3 do atleast. Most European providers do. For customers, though not inter-provider. -danny
Re: BGP to doom us all
On Monday, March 3, 2003, at 06:52 AM, Kuhtz, Christian wrote: Why not? Well, it depends on what you want to use LDAP for. For example, take a naive approach: your router crashes. It comes back up. It receives 130,000 prefixes that it needs to validate. For each prefix, your router must do an LDAP query. Can you be more specific as to why you think that LDAP is not suitable? Relatively heavyweight connections and no caching. Rgds, -drc
Re: BGP to doom us all
> It has to be separate from SWIP though, as rwhois servers don't issue SWIP. This is basically where I started thinking about LDAP. If rwhois doesn't do the job, then we could either fix/enhance rwhois or move to something else. Anyone who has ever delved into the internals of rwhoisd knows what kind of quick hackery it is, therefore moving to something else is the only realistic option. LDAP is designed for read-mostly databases therefore it does support updating the database as long as the frequency of updates is low. So it is entirely practical for LDAP to be used as a replacement for SWIP, i.e. sending update transactions to an aggregating database. If you want to try some of this, the open source server from http://www.openldap.org is the place to start. But please consider developing tools in Java/jython or Python or Ruby rather than Perl. This makes it a lot easier for other people to re-use, improve and contribute http://www.jython.org/ http://python-ldap.sourceforge.net/ http://ruby-ldap.sourceforge.net/ --Michael Dillon
Re: BGP to doom us all
From: "Avi Freedman" > : Why don't SWIP forms include Origin-AS? > > Ahem. Origin-AS(s) - plural. Agreed - mildly. Of course, SWIP isn't > updated when delegation info changes, so origin AS(s) would get just as > stale as contact info. > If networks are filtering based on SWIP information, it will get updated. Personally, I think ARIN handling routing information is an excellent idea. It has to be separate from SWIP though, as rwhois servers don't issue SWIP. On the other hand, if ARIN authoritates the block to the AS and then a lookup to the AS's server provides any subdelegations, that might work. -Jack
Re: BGP to doom us all
> Too many features layered on a single tool. Haq the tool > and the dependencies will cripple your service offering. LDAP is not a tool, it is a protocol that can be used by many tools to communicate in the same way that many servers (BIND, NSD, DJBDNS, MS-DNS, QuickDNS) can use the DNS protocol to communicate with countless clients (Netscape, sendmail, ...). That's why I originally said the following > > I believe that LDAP can be the core of this toolset. If you build a tool that queries the ARIN LDAP server then you can mirror ARIN on your own LDAP server and the tool doesn't have to change. Or you can have a caching LDAP client/server that works and the tool doesn't have to change. If you offer your mirror of ARIN's data (or your caching LDAP server) to your customers for configuring their firewalls, then the firewall manufacturers will almost certainly add support for LDAP-based filter config to their product. That's because LDAP is a widely implemented and deployed industry standard protocol. Once firewalls are configuring dynamically based on either a trusted ISP's mirror of ARIN or a trusted firewall vendor's mirror of ARIN, then these bogon issues will go away. That's because we will have the knobs to turn on and off address space dynamically. Spammers won't be able to use unregistered addresses because everybody will be indirectly trusting ARIN's database. And they won't be able to use the unused parts of registered blocks because ISP's will publish their usage in their own LDAP servers that will be part of the ARIN trust hierarchy. Once this begins to provide benefit in North America, the rest of the world will soon follow. --Michael Dillon
Re: Who uses RADB? [was BGP to doom us all]
On Mon, 3 Mar 2003 [EMAIL PROTECTED] wrote: > Very subtle, David. As it happens, somebody asked only last week if > they could take up the project again. For those who think mapping > filters to route objects is nigh trivial, there is a significant > difference between network assignees and routes. Tracking assignments, > ASNs, customer routing policy, and which edge router each connects to > requires two scoops of Perl. Its not trivial, but there are several proof's of existance out there. I think Worldcom even owned the code for at least two working implementations at one time or another :-) Essentially a route registry is a way to tell everyone "only listen to this route/prefix from me." But if every ISP runs their own route registry, you end up with the same problem with an additional level of indirection. C&W's route registry says their route, Level 3's route registry says their route, Verio's route registry says their route. Etc with Merit, ARIN, RIPE. However, it is a step forward to get the informaton in a common format which can be shared/munged/checked/etc. The route vectors in BGP are very information limited. RPSL/rWHOIS has the opportunity to provide more context.
Re: BGP to doom us all
> > I believe that LDAP can be the core of this toolset. > Why not put everything into a MySQL db? :) Arrgghhh!!! he yells running and screaming in horror... Of all the example products you could have chosen to represent database software, why on earth did you choose this abomination. Is it a dbm-style unordered hash or a B+tree database or an SQL relational database? No, none of the above, it's a stew of pieces hacked from all the above-mentioned carcasses all boiled up in a pressure-cooker until nothing is left but a quick meal. If you had asked, why not use a relational or SQL database, I would have answered thusly. There's nothing wrong with relational databases even those using SQL. However, these are storage systems and I suggested a communications protocol, namely LDAP. If you want to store your directory data in an SQL database and serve it up via LDAP, this can be done with most of the commercial LDAP servers and with openLDAP as well. IBM has done some good work in showing how an LDAP schema can be effectively mapped into an SQL database schema. > LDAP is a fine tool but it was not designed to do some > of the things that other tools do. This applies to SQL/relational databases as well. In fact, LDAP was specifically designed to do things that SQL/relational systems don't do very well. And the set of things that LDAP does maps quite well to things like directories, DNS, whois, rwhois, IRR, RIPEdb, PKI and similar things. More or less, relational systems handle tables well, while LDAP handles hierarchically structured data objects well. In the relational world the focus is on the storage systems and the standards are application programming interfaces like SQL or ODBC. In the LDAP world, the focus is on an efficient and effective communications protocol that can be the frontend to any storage system. > We are not yet at the > point where all we have the the LDAP hammer so everything > looks like a db-nail. I beg to differ. We are at the point where there are numerous commercial LDAP servers, where Sun and Microsoft have integrated LDAP into their OS for yp/NIS types of services and where the open-source server has matured and become a credible solution for serving LDAP. Added to this are the large number of LDAP-related tools for browsing, schema design, interfacing, replication/backup etc. And then there are the many books on LDAP and the courses on LDAP and the fact that LDAP knowledge is a basic part of the skillset for certification by Novell, Microsoft, Cisco, Sun, etc. We all do have the LDAP hammer or we can easily rent or buy one. And we can easily find people who know what one is and who know how to use it. Have you ever tried to hire someone with rwhois experience or RADB experience? If so, put out the same ad asking for LDAP experience and note how much larger the pile of resumes is. In the early '90's the Internet community had to invent a lot of protocols and tools to make things work. Today, this is no longer necessary because we can leverage a lot of stuff from the commercial world. The military have discovered the same thing and generally look for COTS solutions before building their own. I'm not saying that we never have to design another protocol, just that we should use more pre-existing work by others in those areas where our needs are not so unique. --Michael Dillon
Re: Who uses RADB? [was BGP to doom us all]
I'm thrilled to hear that that project is being picked up again. The long-term benefits (IMO) are worth the non-trivial amount of effort required to make a functioning solution. --- [EMAIL PROTECTED] wrote: > Very subtle, David. As it happens, somebody asked > only last week if > they could take up the project again. For those who > think mapping > filters to route objects is nigh trivial, there is a > significant > difference between network assignees and routes. > Tracking assignments, > ASNs, customer routing policy, and which edge router > each connects to > requires two scoops of Perl. > > I should also point out that three out of four RIRs > run a route registry. > http://www.arin.net/tools/rr.html > > Lee > > = David Barak -fully RFC 1925 compliant- __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Re: BGP to doom us all
Too many features layered on a single tool. Haq the tool and the dependencies will cripple your service offering. Now I don't want to say that you can't do this on your own, I am uncomfortable with such tactics being promoted as the one true way that all modern thinkers should adopt. > > Why not? Can you be more specific as to why you think that LDAP is not > suitable? > > Thanks, > Christian > > > I believe that LDAP can be the core of this toolset. > > > > --Michael Dillon > > > Why not put everything into a MySQL db? :) > > LDAP is a fine tool but it was not designed to do some > of the things that other tools do. We are not yet at the > point where all we have the the LDAP hammer so everything > looks like a db-nail. > > --bill > > > * > "The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential, proprietary, and/or > privileged material. Any review, retransmission, dissemination or other use > of, or taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete the material from all > computers." >
Re: Who uses RADB? [was BGP to doom us all]
Very subtle, David. As it happens, somebody asked only last week if they could take up the project again. For those who think mapping filters to route objects is nigh trivial, there is a significant difference between network assignees and routes. Tracking assignments, ASNs, customer routing policy, and which edge router each connects to requires two scoops of Perl. I should also point out that three out of four RIRs run a route registry. http://www.arin.net/tools/rr.html Lee On Sun, 2 Mar 2003, David Barak wrote: > Date: Sun, 2 Mar 2003 19:54:26 -0800 (PST) > From: David Barak <[EMAIL PROTECTED]> > To: Joe Abley <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: Who uses RADB? [was BGP to doom us all] > > > > --- Joe Abley <[EMAIL PROTECTED]> wrote: > > Generating route filters from the IRR via a small > > lump of script has > > the potential to be cheaper, quicker, more efficient > > and less > > customer-enraging than the common alternative > > approach of opening six > > different tickets with the NOC and sacrificing small > > animals for three > > weeks until the updates are made. > > When I was at $LARGE_PROVIDER, I was working on a > project to port all of the customer IP information > over to route-objects for precicely this purpose: the > goal was that customers would be able to update their > filters automatically (and get rWHOIS for free - > simplifying additional ARIN allocation requests). > > Sadly for that project, after I left, the little Ultra > 5 was abandoned, and AFAIK is still sitting in my old > lab, unused - and after the most recent (quarterly) > staff-bloodletting, there certainly won't be resources > to devote to a project like that. Sigh. > > > > = > David Barak > -fully RFC 1925 compliant- > > __ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ >
RE: BGP to doom us all
Why not? Can you be more specific as to why you think that LDAP is not suitable? Thanks, Christian > I believe that LDAP can be the core of this toolset. > > --Michael Dillon > Why not put everything into a MySQL db? :) LDAP is a fine tool but it was not designed to do some of the things that other tools do. We are not yet at the point where all we have the the LDAP hammer so everything looks like a db-nail. --bill * "The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers."
Re: BGP to doom us all
> I believe that LDAP can be the core of this toolset. > > --Michael Dillon > Why not put everything into a MySQL db? :) LDAP is a fine tool but it was not designed to do some of the things that other tools do. We are not yet at the point where all we have the the LDAP hammer so everything looks like a db-nail. --bill
RE: BGP to doom us all
Good point, Sean. The problem is the business process and the risk to the process, vs. the cost to fix it. Jim -Original Message- From: Sean Donelan [mailto:[EMAIL PROTECTED] Sent: Friday, February 28, 2003 7:25 PM To: '[EMAIL PROTECTED]' Subject: Re: BGP to doom us all On Fri, 28 Feb 2003, Jim Deleskie wrote: > http://news.com.com/2100-1009-990608.html?tag=fd_lede1_hed > > Seems the BGP will be the down fall of the internet, the sky is falling the > sky is falling Other than pending patents and a cool name Secure BGP, you still have the fundamental problem. Garbage In, Garbage Out. The only difference is now you have Secure Garbage(tm). There is a problem that needs to be solved. But like the whole micro-payments, SET, etc thing; if the solution is more complicated and more expensive than the alternatives; it won't get used no matter how "secure" it is.
Re: BGP to doom us all
From: "Avi Freedman" > > "Router CPUs average 50%, and S-BG adds 10%" (paraphrase) > Average is somewhat less relevant than common peaks. > GSRs and 7500s and 7200s all get up there at 90+% on the real Internet. > I agree. I'm have a tricked 7200 managing 3 peers. Normal traffic utilization rate is 30% cpu usage. The BGP scan kicks 90%+ cpu. During DDOS attacks, the hardest part to stabilizing the system is CPU resource management and in particular BGP stability. Often, one peer has to be shut down to maintain stability on the other two. At that point, work can continue to track and block the DDOS. Then all peers can be brought up, but depending on the severity of the attack, cpu can still be cranking 90-96%, but at least stable traffic. Changes to how we do BGP have effects beyond just BGP routing. It also effects other routing and network issues. > And with the assumption that people will be willing to front their big > iron with offboard routing CPU boxes. > Offload routing? To where? A server running an OS that can't run 1/2 the life of my router without a reboot? To a port adapter that my router doesn't have room for? Or do I need to call Cisco and say, "Congrats! You finally get to sell me that $140,000 7500 series router I previously couldn't afford and didn't quite need yet." Here's the kicker. I couldn't inject a route that wasn't mine into any of my peers without calling them first and asking permission. My network doesn't gain anything, but I lose alot. > I just don't see these things happening. And even if they could/would, > I think S-BGP needs more paranoid simulation/attack/analysis before it > in particular could be the grand fix. > I agree. Deployment would also be long in coming. I may run an all Cisco network, but I don't run any code past 12.0, and when possible, GD releases only. From deployment of the finalized protocol, I'd expect a 3-5 year wait (probably longer) before the protocol reaches a Cisco GD maturity level. -Jack
Re: BGP to doom us all
On Mon, Mar 03, 2003 at 11:53:51AM +, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote a message of 55 lines which said: > Yes there are other ways and I suggest that the optimal choice of protocol > for publishing this information is LDAP, not DNS. ... > Next step is to get ISPs to replace their creaking antiquated rwhois > servers with LDAP servers. Technically, this is reasonable, and I suggest that everybody who shares this view do some actual work in the IETF working group which is precisely devoted to the subject : Crisp http://www.ietf.org/html.charters/crisp-charter.html>. LDAP is one of the two actual proposals discussed at Crisp, the new IRIS protocol being the other. Do note that Crisp explicitely works also on address registries, not just domain registries. > I am suggesting that the starting point here is to get ARIN to set up an > LDAP server to authoritatively identify the leaseholder for all IP address > space. I suggested the same to the RIPE-NCC some time ago. No real interest. I believe that the RIRs have enough work :-} They do not seem to participate in Crisp either :-(
Re: BGP to doom us all
> I like the idea of people being able to START on the authentication > datbase of ownership/announcement in a distributed fashion, but > perhaps there are other ways (perhaps DNS-based) of getting there > as well... Yes there are other ways and I suggest that the optimal choice of protocol for publishing this information is LDAP, not DNS. That's because there is no need for kludges to get the data that you need into LDAP since it supports a wide variety of data types. It can also be used in a hierarchical referral chain just like DNS. I am suggesting that the starting point here is to get ARIN to set up an LDAP server to authoritatively identify the leaseholder for all IP address space. Next step is to get ISPs to replace their creaking antiquated rwhois servers with LDAP servers. And then build up tools that use the data from the LDAP hierarchy to generate route filters, configure firewalls, manage SMTP filters, etc. If people want a PKI cert hierarchy, that data can go into the same servers. If people want to have secure BGP sessions they can have their network management system talking to the LDAP hierarchy to check certs and then tell their routers what to do. A router should never have to do any crypto itself. > : My opinion is that lazy operational practices are the single biggest threat to > : the Internet. One of the lazy operational practices is the proliferation of crudely hacked tools, often written in PERL which is like a swiss army knife made by tying together a knife, pliers, nailfile and screwdriver using dental floss and duct tape. There was a time when the net was growing too fast to plan and nobody had any experience or any benefit of hindsight. But times have changed and we now need to replace some of this rotting infrastructure with better general purpose tools that have some architectural planning behind them. Something like a Leatherman tool or a Victorinox swiss army knife. I believe that LDAP can be the core of this toolset. I also believe that we need to stop relying on the packet-forwarding box to do the entire job of routing and start using more auxiliary CPU power in a vendor independent way. There is plenty of experience in building rackmount Intel-based BSD/Linux servers that run as reliably as the routers themselves. Let these boxes do the job of authenticating and authorising route exchange and similar jobs. --Michael Dillon
Re: Who uses RADB? [was BGP to doom us all]
--- Joe Abley <[EMAIL PROTECTED]> wrote: > Generating route filters from the IRR via a small > lump of script has > the potential to be cheaper, quicker, more efficient > and less > customer-enraging than the common alternative > approach of opening six > different tickets with the NOC and sacrificing small > animals for three > weeks until the updates are made. When I was at $LARGE_PROVIDER, I was working on a project to port all of the customer IP information over to route-objects for precicely this purpose: the goal was that customers would be able to update their filters automatically (and get rWHOIS for free - simplifying additional ARIN allocation requests). Sadly for that project, after I left, the little Ultra 5 was abandoned, and AFAIK is still sitting in my old lab, unused - and after the most recent (quarterly) staff-bloodletting, there certainly won't be resources to devote to a project like that. Sigh. = David Barak -fully RFC 1925 compliant- __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Re: Who uses RADB? [was BGP to doom us all]
On Sunday, Mar 2, 2003, at 14:06 America/Vancouver, [EMAIL PROTECTED] wrote: It doesnt cost a million dollars to have access to a RR, its somewhat less! You pay for your domains you pay for your IPs you pay for your ASN you pay for your SSL, so why be shocked you pay a little for this too? And if everyone filters your prefixes that will be operational value enough to join! Because it provides me *no* service what so ever. Then don't use it. Surely this is not rocket science. If it provides no service to me and the guy next block and another little ISP that is announcing some prefixes and a few large ISPs that announce quite a few prefixes you wont get the data that you need. I am sure you get the idea. Some people seem to have the idea that RADB-like services are only useful if every operator uses them, and every operator publishes accurate information. In my experience, that is not the case. The most common usefulness I have experienced out of the IRR is as an automated mechanism for publishing policy to adjoining ASes. Examples are BGP-speaking customers instructing their providers on how to filter their advertisements, and ASes filtering advertisements from their peers (which does happen, even if it's not common in the US). Whether or not non-adjoining ASes use the IRR at all, or use it well, is not relevant to this application. Generating route filters from the IRR via a small lump of script has the potential to be cheaper, quicker, more efficient and less customer-enraging than the common alternative approach of opening six different tickets with the NOC and sacrificing small animals for three weeks until the updates are made. Joe
Re: Who uses RADB? [was BGP to doom us all]
> >> It doesnt cost a million dollars to have access to a RR, its somewhat > >> less! You pay for your domains you pay for your IPs you pay for your > >> ASN you pay for your SSL, so why be shocked you pay a little for this > >> too? And if everyone filters your prefixes that will be operational > >> value enough to join! > > > > Because it provides me *no* service what so ever. > > Then don't use it. Surely this is not rocket science. If it provides no service to me and the guy next block and another little ISP that is announcing some prefixes and a few large ISPs that announce quite a few prefixes you wont get the data that you need. I am sure you get the idea. Alex
Re: Who uses RADB? [was BGP to doom us all]
On Saturday, Mar 1, 2003, at 11:28 America/Vancouver, [EMAIL PROTECTED] wrote: It doesnt cost a million dollars to have access to a RR, its somewhat less! You pay for your domains you pay for your IPs you pay for your ASN you pay for your SSL, so why be shocked you pay a little for this too? And if everyone filters your prefixes that will be operational value enough to join! Because it provides me *no* service what so ever. Then don't use it. Surely this is not rocket science. What does a RADB tell you about a non-transit network that you can't see It tells you who it belongs to, where it should be coming from, possibly contact details. Presuming that it is correct, which it is NOT in a large percentage of cases. So again, why am I paying to someone to provide me incorrect information? You're not. You're paying to provide other people with information about you. Retrieving other peoples' incorrect information is free. Joe
Re: BGP to doom us all
On Fri, 28 Feb 2003, Vadim Antonov wrote: > > > > Thank you very much, but no. > > DNS (and DNSSEC) relies on working IP transport for its operation. Doesn't sBGP also have this problem? A catch-22 where you have to have good routing to get good routing? Or did I miss something? > > Now you effectively propose to make routing (and so operation of IP > transport) dependent on DNS(SEC). > > Am I the only one who sees the problem? > > --vadim > > PS. The only sane method for routing info validation I've seen so far is > the plain old public-key crypto signatures. > > > On 1 Mar 2003, Paul Vixie wrote: > > > > > It wouldn't be too hard for me to trust: > > > > > > 4969.24.origin.0.254.200.10.in-addr.arpa returning something like "true." > > > to check whether 4969 is allowed to originaate 10.200.254.0/24. ... > > > > at last, an application for dnssec! > >
Re: BGP to doom us all
On Sun, 2 Mar 2003, Avi Freedman wrote: > In article <[EMAIL PROTECTED]> The Great Sean wrote: ^^ > : I'll be stupid, and ask some questions I've always wondered about. > : Why should routes learned by eBGP have a higher priority than iBGP? > Love to know myself. Consider the situation where two routers have an external path to a destination, but they both prefer the path over the other. This can create routing loops and BGP instability as routers keep revoking and reannouncing their external routes over iBGP. However, the "external first" rule is a relatively weak one, as it only kicks in when the BGP route selection algorithm can't decide which route is better. If you use the local preference, AS path or multi-exit discriminator to prefer one of the BGP routes, all routers will use this one, regardless of whether they learn it over eBGP or iBGP.
Re: BGP to doom us all
In article <[EMAIL PROTECTED]> The Great Sean wrote: : I'll be stupid, and ask some questions I've always wondered about. : Why should routes learned by eBGP have a higher priority than iBGP? Love to know myself. Took me a few years to figure out why the strange iBGP redistribution rules (because barring something like confeds or RRs, there's no loop detection method in iBGP w/o it...) : Why should BGP implementations flap all good routes when they see a single : bad route packet? Sorry if this isn't adding enough signal, but Amen! However, there's some disagreement historically about this. I am in the camp who thinks the danger is higher from being able to trigger massive #s of session drops cyclically, but some argue that it's worse to continue talking to someone who may be spewing badness that you only see as syntax error, but some packets may have OK syntax and bad contents. This may be doomed to the neverending debate category, but I feel fairly strongly that I'd at least like a knob that makes NOTIFY not kill sessions (but you'd probably need to twist it it at both ends of the session). : Why don't SWIP forms include Origin-AS? Ahem. Origin-AS(s) - plural. Agreed - mildly. Of course, SWIP isn't updated when delegation info changes, so origin AS(s) would get just as stale as contact info. Avi
Re: BGP to doom us all
On Sun, 2 Mar 2003, Sean Donelan wrote: > Why should routes learned by eBGP have a higher priority than iBGP? In general, isn't it better that they pay to carry the traffic across the world on their network, rather than you? > Why don't SWIP forms include Origin-AS? Good question...but is it too late? Would seem like a more-worthy effort than forcing security into bgp...at least in the interim. If nothing else, it would seem like the route dbs solved a problem that should never have existed in the first place. Why isn't that totally integrated with network assignment? Why have multiple authorities? To me, the lack of true authority makes the radb and friends advisory bodies at best. What we really need is an authoritative body. Somebody who can say, without a doubt (and without having to pay an additional maintenance fee or maintain multiple objects with multiple routing arbiters), who should be allowed to announce which prefix. Andy Andy Dills 301-682-9972 Xecunet, LLCwww.xecu.net Dialup * Webhosting * E-Commerce * High-Speed Access
Re: BGP to doom us all
On Fri, 28 Feb 2003, Steven M. Bellovin wrote: > >> My own opinion is that sophisticated routing attacks are the > >> single biggest threat to the Internet. > > > >My opinion is that lazy operational practices are the single biggest threat to > >the Internet. What's the point of building security and robustness into a syst > >em > >when people choose not to turn it on? > > > > "Never attribute to malice what can be explained by incompetence". How do you tell the difference? There have been weird routing problems on the Net for a long time. Some have been large, and quickly fixed. Others have been small, and aren't fixed (as quickly). Some don't even cause problems, but route traffic through unusual places. There have been a few poison packets over the years which crashed alternate implementations. Although I still think the recovery mechanism was sometimes worse than the problem. I'll be stupid, and ask some questions I've always wondered about. Why should routes learned by eBGP have a higher priority than iBGP? Why should BGP implementations flap all good routes when they see a single bad route packet? Why don't SWIP forms include Origin-AS?
Re: Who uses RADB? [was BGP to doom us all]
On Sat, Mar 01, 2003 at 11:31:30AM -0500, Mark Radabaugh wrote: > > > > So, let's recap why no one uses them (as many have said already in the > related > > thread): Laziness. The same laziness that results in the slew of other > things > > many folks have pointed out not being addressed. > > > > -danny > > > > You forgot the other one - expense. AFAIK all of the registries have fees > or require you to be a customer. If there is no operational value for me > why would I want to spend the money? I realize most of you work for ALTDB? www.altdb.net even verio mirrors altdb so customers can use them instead of the verio registry if you want. http://info.us.bb.verio.net/routing.html#VRR -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: BGP to doom us all
In article <[EMAIL PROTECTED]> Vadim wrote: : Thank you very much, but no. : DNS (and DNSSEC) relies on working IP transport for its operation. Good point. However - Routers rely on having enough CPU and RAM to do transport as well, and router engineers rely on not running offboard boxes in strange configurations that are more likely to cause that which is the biggest of problems on the Internet - humans getting confused and stuffing things up. Problems abound with every approach. : Now you effectively propose to make routing (and so operation of IP : transport) dependent on DNS(SEC). : Am I the only one who sees the problem? Probably not, but lots of us see problems with S-BGP as constituted now. Lots of work has gone into something that is highly unlikely to be deployed in any major core network. : --vadim Rather than flame each other, maybe we can have a shoot-the-shit discussion of the underlying problem (lack of authentication of routing AND of packet sources), perhaps at IETF or NANOG, at the pre-draft stage. Maybe people will agree, but it might be productive. : PS. The only sane method for routing info validation I've seen so far is : the plain old public-key crypto signatures. Avi
RE: Who uses RADB? [was BGP to doom us all]
> On Sat, 1 Mar 2003, Mark Radabaugh wrote: > > > Who actually uses RADB to build filters other than Verio? While my > > experience with other providers is limited Verio is the only one (of the > > ones we have used) who used RADB entries for BGP peers. > > AFAIK, Level3 and C&W. Teleglobe as well (mirror), unless late to me unknown changes. mh > I have to keep RADB entries (actually altdb, and > c&w's own) up to date in order for each of them to accept our routes and > our BGP customers' routes. > > > Overall it wasn't the best solution IMHO for a couple of reasons: > > > > - there was nothing to keep us from making bogus entries in the RADB > > - filters were only updated once a day making changes slow > > OTOH, they don't have to pay someone to answer and respond to email sent > to bgp-admin. They won't accept routes you accidentally leak to > them. Is > it secure? Not really. Is it cheap, reliable automation, I suspect so. > > > This is not meant as a complaint toward Verio - I'm simply > trying to decide > > why we should go to the added expense of entering our routes in > a RADB. To > > date I have seen no operational difference between using RADB > and not using > > www.altdb.net. No expense other than the time you spend keeping your > objects up to date. > > -- > Jon Lewis [EMAIL PROTECTED]| I route > System Administrator| therefore you are > Atlantic Net| > _ http://www.lewis.org/~jlewis/pgp for PGP public key_ > >
Re: BGP to doom us all
On Sat, 1 Mar 2003, Avi Freedman wrote: > Re: S-BGP in particular, I think that the analysis on S-BGP has been... > limited. Ironic for a security protocol that I haven't seen any > real analysis of the effect on router CPUs when *under attack*. I > am not saying "oh, the authentication will drive things way too high". > I'm just saying that we don't know because the simulations have used > very conservative parameters. My two cents: By looking at the packet formats I estimate that the memory requirements for S-BGP are about 4 times those of regular BGP (mind you - just the BGP table, RIB and FIB remain the same). This gets us pretty close to common 32-bit CPU address space limits. For receiving updates: you are expected to check the validity of each hop in each AS path in the global routing table using a public key signature verification. A Pentium-class CPU can do a few thousand of those per second, so that adds several minutes of pure CPU time to the initialization of each full feed. This means crypto hardware. For sending updates: you must include the identity of the receiver in each update (and then sign the update, unless I remember incorrectly). That means sending out updates to a large number of peers (such as on a public internet exchange) becomes a rather expensive operation, even discounting the crypto. However, there is an alternative to S-BGP: soBGP (secure origin BGP, see URL in my sig for links). Unlike S-BGP, soBGP mainly focusses on the origin of a route. At first sight this would make soBGP less secure than S-BGP, but it looks like S-BGP can't protect the entire path under all circumstances anyway. Also, soBGP is a more open protocol, which can easily be extended with additional security checks. And a big plus for soBGP is that unlike S-BGP, where the security information is stored in path attributes (which means you can easily bring down an existing router by sending it S-BGP info, no filtering on unknown attributes AFAIK), this information is exchanged using a new type of message. This makes it possible to offload the security processing to an external box. The problem with fully protecting the path (such as S-BGP wants to do) is that the only way to do this well is to have the source say which paths are good, but this is simply too much information. Without this, it becomes possible for someone who legitimately received the route to propagate it even though the source didn't intend this. Also, giving the source full control makes dynamic rerouting (like 9/11 emergency transit) much, much harder. Obviously we all want routes we know are good, and don't want routes we know are bad. That's wat S-BGP and soBGP can do. But what if we can't determine if routes are good or bad? If you reject the routes you break a lot of connecitvity. If you don't, nobody will bother jumping through all the hoops to make their route authenticity verifiable. I really don't envy the first operator to deploy (S-|so)BGP... -- Iljitsch van Beijnum - http://www.bgpexpert.com/ (updated: Feb 27, 0:40:21)
Re: Who uses RADB? [was BGP to doom us all]
> A) Verio provides a free db for its customers They're not the only ones, CWI and Level3 do as well, off the top of my head. > B) Altdb is free, and works great That it does, round of applause for Steve :) Jeff -- Jeffrey Meltzer ICS/VillageWorld 631-218-0700 x100
Re: Who uses RADB? [was BGP to doom us all]
On Sat, Mar 01, 2003 at 10:20:43AM -0500, Mark Radabaugh wrote: > > This is not meant as a complaint toward Verio - I'm simply trying to > decide why we should go to the added expense of entering our routes in a > RADB. To date I have seen no operational difference between using RADB > and not using it. A) Verio provides a free db for its customers B) Altdb is free, and works great C) If you have any sizable number of transits, routes, or BGP speaking customers, you'll find it infinitely easier to write a 10 line script using IRRToolSet than it is to e-mail or call your providers with every change. D) A smart company concerned with ease of use could take a php monkey off the street and for $200 create a nice web interface for customers to manage their entries in an IRR db. -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Who uses RADB? [was BGP to doom us all]
> It doesnt cost a million dollars to have access to a RR, its somewhat less! You > pay for your domains you pay for your IPs you pay for your ASN you pay for your > SSL, so why be shocked you pay a little for this too? And if everyone filters > your prefixes that will be operational value enough to join! Because it provides me *no* service what so ever. > > What does a RADB tell you about a non-transit network that you can't see > > It tells you who it belongs to, where it should be coming from, possibly contact > details. Presuming that it is correct, which it is NOT in a large percentage of cases. So again, why am I paying to someone to provide me incorrect information? Alex
Re: Who uses RADB? [was BGP to doom us all]
On Sat, 1 Mar 2003, Mark Radabaugh wrote: > Who actually uses RADB to build filters other than Verio? While my > experience with other providers is limited Verio is the only one (of the > ones we have used) who used RADB entries for BGP peers. AFAIK, Level3 and C&W. I have to keep RADB entries (actually altdb, and c&w's own) up to date in order for each of them to accept our routes and our BGP customers' routes. > Overall it wasn't the best solution IMHO for a couple of reasons: > > - there was nothing to keep us from making bogus entries in the RADB > - filters were only updated once a day making changes slow OTOH, they don't have to pay someone to answer and respond to email sent to bgp-admin. They won't accept routes you accidentally leak to them. Is it secure? Not really. Is it cheap, reliable automation, I suspect so. > This is not meant as a complaint toward Verio - I'm simply trying to decide > why we should go to the added expense of entering our routes in a RADB. To > date I have seen no operational difference between using RADB and not using www.altdb.net. No expense other than the time you spend keeping your objects up to date. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Who uses RADB? [was BGP to doom us all]
> It doesnt cost a million dollars to have access to a RR, its somewhat less! You > pay for your domains you pay for your IPs you pay for your ASN you pay for your > SSL, so why be shocked you pay a little for this too? And if everyone filters > your prefixes that will be operational value enough to join! > Correct. We pay for lots and lots of things - and there are about 30 other things I need NOW that cost $500. > You've been reading this thread right? Those were the reasons and they were > pretty good, if you dont you may get filtered eventually or have your routes > hijacked. > Eventually is not now - and given that you have a horrendous chicken and egg problem I don't see it happening anytime in even the remote future. I'll grant you that it would be nice to have it so that my routes can't be hijacked - but we are back to the same chicken and egg problem. I'm contributing to one end of it - but I'm not the hard one to convince here. It's the many thousands of others who don't read NANOG. > Well you cant arbitrarily register routes to them, you have to be a member, and > have to match the authorisation criteria. I use RIPE and you have to be > authorised on both the ASN and the INETNUM objects to register the route for it. > True enough. And to get my BGP peers to accept my routes I have to do the exact same thing by communicating with them - not just changing entries in the RADB. If I want to launch a malicious attack both methods leave trails - but I'm willing to bet that it's a lot more likely that a person reviewing my request at a BGP peer will catch me before an automated system. Even if you compromise my routers it still doesn't allow you to announce anything interesting from me - you still have to convince my upstream providers to accept the announcements based on the current system of manually entered prefixes. We have had our routes registered in RADB in the past but despite the theory that it is laziness we dropped it due to expense and lack of relevence. I'll probably register our routes again but until RADB becomes a requirement of the RIR's or someone with authority I rather suspect this is a dead end. > Steve Mark
Re: Who uses RADB? [was BGP to doom us all]
> You forgot the other one - expense. AFAIK all of the registries have fees > or require you to be a customer. If there is no operational value First problem, you see no "operational value". > for me why would I want to spend the money? Money changing hands no longer makes the IRR a dis-interested third party or research project, they now have a vested interested in object integrity and availability, and perhaps can afford resources to support these and other enhancements. > I realize most of you work for companies that consider a million dollars > chump change but that is not the case everywhere. If you can give me a > convincing reason to register my routes in a RADB I will - but at this > point I have yet to see it. When one of your peers starts filtering inter-provider based on IRR and your prefixes aren't permitted, or one of your peers advertises you more- specifics for your customers prefixes, or better yet, your routers are compromised and used to disrupt service to some now very unhappy multi- million dollar online enterprise that will seek reimbursement -- maybe that'll help convince you... > What does a RADB tell you about a non-transit network that you can't see > from BGP and WHOIS? There is no more security in RADB than there is in our > current method of notifying our peers of the netblocks we are announcing. You should read up on it, there's a bit more capability there than just a prefix and POC email address. -danny
Re: Who uses RADB? [was BGP to doom us all]
On Sat, 1 Mar 2003, Mark Radabaugh wrote: > > So, let's recap why no one uses them (as many have said already in the > related > > thread): Laziness. The same laziness that results in the slew of other > things > > many folks have pointed out not being addressed. > > > > -danny > > You forgot the other one - expense. AFAIK all of the registries have fees > or require you to be a customer. If there is no operational value for me > why would I want to spend the money? I realize most of you work for It doesnt cost a million dollars to have access to a RR, its somewhat less! You pay for your domains you pay for your IPs you pay for your ASN you pay for your SSL, so why be shocked you pay a little for this too? And if everyone filters your prefixes that will be operational value enough to join! > companies that consider a million dollars chump change but that is not the > case everywhere. If you can give me a convincing reason to register my > routes in a RADB I will - but at this point I have yet to see it. You've been reading this thread right? Those were the reasons and they were pretty good, if you dont you may get filtered eventually or have your routes hijacked. > What does a RADB tell you about a non-transit network that you can't see It tells you who it belongs to, where it should be coming from, possibly contact details. > from BGP and WHOIS? There is no more security in RADB than there is in our > current method of notifying our peers of the netblocks we are announcing. Well you cant arbitrarily register routes to them, you have to be a member, and have to match the authorisation criteria. I use RIPE and you have to be authorised on both the ASN and the INETNUM objects to register the route for it. Steve
Re: Who uses RADB? [was BGP to doom us all]
> So, let's recap why no one uses them (as many have said already in the related > thread): Laziness. The same laziness that results in the slew of other things > many folks have pointed out not being addressed. > > -danny > You forgot the other one - expense. AFAIK all of the registries have fees or require you to be a customer. If there is no operational value for me why would I want to spend the money? I realize most of you work for companies that consider a million dollars chump change but that is not the case everywhere. If you can give me a convincing reason to register my routes in a RADB I will - but at this point I have yet to see it. What does a RADB tell you about a non-transit network that you can't see from BGP and WHOIS? There is no more security in RADB than there is in our current method of notifying our peers of the netblocks we are announcing. Mark Radabaugh Amplex (419) 720-3635
Re: Who uses RADB? [was BGP to doom us all]
> as you say for customers only. Inter-provider we have basic bogon checking plus > maximum prefix. Its too unwieldy to build when you have peers exchanging > thousands of routes... theres a belief that the peer should be behaving > responsibly tho and this is a condition of most bilateral peering contracts. Unfortunately, contracts don't fix mis-(or malicious-) configurations on compromised routers or from a peers disgruntled worker. > Going back to the original topic on this thread I would expect a deliberate > attack on BGP routing to come from a customer not a provider such as Level3, if > they are filtering in turn to their customers we have a reasonable amount of > sanity checking going on A large provider I worked for in the past had a router maliciously configured to inject a more-specific prefix for a very "popular network". Even the "popular networks" provider sent the traffic to us. Had explicit prefix-based inter- provider filtering been in place it would not have occurred, or at least "the whole Internet" wouldn't have been affected. With the IRRs and inter-provider filtering it's the whole chicken and egg thing. Inter-provider filters aren't in place because no one cares about IRRs (even though they have other operational value as well). Vendors don't support the amount of prefix filters required because they say no one uses them. Heck, lots of folks still don't ingress filter routes (or packets) from their customers. When ANS used to employ inter-provider filters the biggest problem was getting them updated and bouncing routes or sessions. That's no excuse anymore because pretty much everyone supports the ability to incrementally update filters, and BGP Route Refresh fixes the bounce the session/route thing. So, let's recap why no one uses them (as many have said already in the related thread): Laziness. The same laziness that results in the slew of other things many folks have pointed out not being addressed. -danny
Re: Who uses RADB? [was BGP to doom us all]
On Sat, 1 Mar 2003, Danny McPherson wrote: > > > > > > Who actually uses RADB to build filters other than Verio? While my > > > experience with other providers is limited Verio is the only one (of the > > > ones we have used) who used RADB entries for BGP peers. > > > > Level3 do atleast. Most European providers do. > > For customers, though not inter-provider. We use them.. as you say for customers only. Inter-provider we have basic bogon checking plus maximum prefix. Its too unwieldy to build when you have peers exchanging thousands of routes... theres a belief that the peer should be behaving responsibly tho and this is a condition of most bilateral peering contracts. Going back to the original topic on this thread I would expect a deliberate attack on BGP routing to come from a customer not a provider such as Level3, if they are filtering in turn to their customers we have a reasonable amount of sanity checking going on Steve
Re: Who uses RADB? [was BGP to doom us all]
> > > Who actually uses RADB to build filters other than Verio? While my > > experience with other providers is limited Verio is the only one (of the > > ones we have used) who used RADB entries for BGP peers. > > Level3 do atleast. Most European providers do. For customers, though not inter-provider. -danny
Re: Who uses RADB? [was BGP to doom us all]
> Who actually uses RADB to build filters other than Verio? While my > experience with other providers is limited Verio is the only one (of the > ones we have used) who used RADB entries for BGP peers. Level3 do atleast. Most European providers do. Neil.
Who uses RADB? [was BGP to doom us all]
> No, the lazy operational implementations of how people deploy BGP > in their networks will be the downfall of the Internet. I see on a daily > basis, wrong announcements, route leaks tripping max-prefixes, RADB > entries that are either totally out of date, completely wrong or > for some large organisations they don't even have RADB entries. > sBGP may [and probably will] help with some of that but its not > a panacea. > > Regards, > Neil. Who actually uses RADB to build filters other than Verio? While my experience with other providers is limited Verio is the only one (of the ones we have used) who used RADB entries for BGP peers. Overall it wasn't the best solution IMHO for a couple of reasons: - there was nothing to keep us from making bogus entries in the RADB - filters were only updated once a day making changes slow This is not meant as a complaint toward Verio - I'm simply trying to decide why we should go to the added expense of entering our routes in a RADB. To date I have seen no operational difference between using RADB and not using it. My view may very well be distorted by the fact that we are not a transit AS :-) Mark Radabaugh Amplex (419) 720-3635
Re: BGP to doom us all
> http://news.com.com/2100-1009-990608.html?tag=fd_lede1_hed > > Seems the BGP will be the down fall of the internet, the sky is falling the > sky is falling No, the lazy operational implementations of how people deploy BGP in their networks will be the downfall of the Internet. I see on a daily basis, wrong announcements, route leaks tripping max-prefixes, RADB entries that are either totally out of date, completely wrong or for some large organisations they don't even have RADB entries. sBGP may [and probably will] help with some of that but its not a panacea. Regards, Neil. -- Neil J. McRae - Alive and Kicking [EMAIL PROTECTED]
Re: BGP to doom us all
> > > > It wouldn't be too hard for me to trust: > > > > 4969.24.origin.0.254.200.10.in-addr.arpa returning something like "true." > > to check whether 4969 is allowed to originaate 10.200.254.0/24. ... > > at last, an application for dnssec! > er, thats been one of the objectives for the last eight+ years. --bill
RE: BGP to doom us all
I'm thankful that I have a sense of humor. :-) Barry is spot on -- this is one of things that I have continually bitched about. The decline of clever engineering in the Internet engineering arena is directly related to (methinks) situations wherein despicable business practices unfortunately override common engineering sense, ignorance mysteriously prevails, and there is a general apathy in doing the Right Thing (tm). - ferg -- "Barry Raveendran Greene" <[EMAIL PROTECTED]> writes: My opinion is that lazy operational practices are the single biggest threat to the Internet. What's the point of building security and robustness into a system when people choose not to turn it on?
Re: BGP to doom us all
Thank you very much, but no. DNS (and DNSSEC) relies on working IP transport for its operation. Now you effectively propose to make routing (and so operation of IP transport) dependent on DNS(SEC). Am I the only one who sees the problem? --vadim PS. The only sane method for routing info validation I've seen so far is the plain old public-key crypto signatures. On 1 Mar 2003, Paul Vixie wrote: > > > It wouldn't be too hard for me to trust: > > > > 4969.24.origin.0.254.200.10.in-addr.arpa returning something like "true." > > to check whether 4969 is allowed to originaate 10.200.254.0/24. ... > > at last, an application for dnssec!
Re: BGP to doom us all
> It wouldn't be too hard for me to trust: > > 4969.24.origin.0.254.200.10.in-addr.arpa returning something like "true." > to check whether 4969 is allowed to originaate 10.200.254.0/24. ... at last, an application for dnssec!
Re: BGP to doom us all
In article <[EMAIL PROTECTED]> Barry wrote: : Now - show me an operational environment on the Internet were this authorization : chain is _working_ today. RIRs and RADB do not count. As you mention before, : those databases and keeping them up to date are a "pulling teeth" exercise. Well, while I don't advocate S-BGP *in particular*, I think starting with something based on in-addr, which is already delegated right down to the level of an origin AS owner (almost always), is the right idea. It wouldn't be too hard for me to trust: 4969.24.origin.0.254.200.10.in-addr.arpa returning something like "true." to check whether 4969 is allowed to originaate 10.200.254.0/24. First level use of something like that would be for detection of unauthorized routing, second could be some level of filtering - perhaps eventually in routing devices, perhaps not. Want authentication? DNSSEC perhaps - but poisoning attacks aside, I assert that if you get root on the in-addr box for a typical network, there are other problems you can cause anyway, especially at edge-y type networks. I think (as usual) we have this political problem with the idea of getting routing databases updated, either because of people who don't want others to see routing policy, or because of those who won't use anything that isn't 100% complete. All I assert about that is that building filters from the existing databases would indeed be silly. : As mentioned here and NANOGs in the past, our biggest problem are providers not : using the tools that they have to build incident resistance into today's : network. Agreed. :> My own opinion is that sophisticated routing attacks are the :> single biggest threat to the Internet. Well, I think redistribution attacks and worms that slam connected IPs with forged-source packets of various types are more worrisome than people leaking malformed BGP updates or trying mass blackholio attacks like the 7007 effect. Those may be sophisticated routing attacks (the former), but I don't really think so. Re: S-BGP in particular, I think that the analysis on S-BGP has been... limited. Ironic for a security protocol that I haven't seen any real analysis of the effect on router CPUs when *under attack*. I am not saying "oh, the authentication will drive things way too high". I'm just saying that we don't know because the simulations have used very conservative parameters. I have problems with statements from S-BGP-land like - "Networks upgrade their routers every 2 years" (paraphrase) Not the last 2 or the next 1. "Router CPUs average 50%, and S-BG adds 10%" (paraphrase) Average is somewhat less relevant than common peaks. GSRs and 7500s and 7200s all get up there at 90+% on the real Internet. And with the assumption that people will be willing to front their big iron with offboard routing CPU boxes. I just don't see these things happening. And even if they could/would, I think S-BGP needs more paranoid simulation/attack/analysis before it in particular could be the grand fix. I like the idea of people being able to START on the authentication datbase of ownership/announcement in a distributed fashion, but perhaps there are other ways (perhaps DNS-based) of getting there as well... : My opinion is that lazy operational practices are the single biggest threat to : the Internet. What's the point of building security and robustness into a system : when people choose not to turn it on? Agreed on point 1! Not on point 2... It is still worth considering what security and robustness one can build in, esp. those things that allow you to do something even if the rest of the 'net doesn't... Avi
Re: BGP to doom us all
Hi, Dean. ] Assuming the router is compromised, so is the MD5 key. And presumably, ] the acls and anything else can be changed as well. Agreed. My point was to take a few steps to avoid the compromise. :) It isn't difficult to make things just a *bit* more difficult, and thus avoid the pain caused by the average scan and sploit crowd. Pick good passwords, limit access, keep routing tables clean, etc. Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
Re: BGP to doom us all
Hi, Alex. ] RCS of your router config is your friend. Yep, agreed. Sanity checking router configurations is a very wise move. Just so everyone knows, the miscreants generally disable all logging capability and enact ACLs to block all ICMP, UDP, and selectively permit telnet from their hacked hosts. These are some of the warning signs. ] Who cares? If the other routers are configured correctly, they wont take ] tainted advertisements. If they are not configured correctly, any Super ] Secure BGP wont help. Yep, thus my constant raving about prefix filtering. :) Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
Re: BGP to doom us all
> > Indeed! Compromised routers (generally Cisco) are routinely traded in > the underground. However, these routers are usually compromised by > taking advantage of weak passwords, e.g. "cisco" for access and enable. :( RCS of your router config is your friend. mailing of the diff between authorized config and running config every N mintues to [EMAIL PROTECTED] is your friend. Not running "trust everything" configuration on your network is your friend. > Some who trade for compromised routers (one cisco is worth approximately > three to five stolen credit cards) specifically ask for routers running > BGP, and may pay a premium for this extra. Who cares? If the other routers are configured correctly, they wont take tainted advertisements. If they are not configured correctly, any Super Secure BGP wont help. Alex
Re: BGP to doom us all
Hi, NANOGers. ] However, given the recent academic popularity of attacks against routers, Indeed! Compromised routers (generally Cisco) are routinely traded in the underground. However, these routers are usually compromised by taking advantage of weak passwords, e.g. "cisco" for access and enable. :( Some who trade for compromised routers (one cisco is worth approximately three to five stolen credit cards) specifically ask for routers running BGP, and may pay a premium for this extra. Trade in compromised Juniper routers is rare, but it does occur. As to what is done with these compromised routers, well, ask me at the next NANOG. There are many things folks can do with existing BGP configurations to make things a bit better. Prefix filtering, both on ingress and egress, MD5 authentication, and ACLs for TCP 179 help. Are they perfect? No, nothing is a panacea. However, raising the bar even a little can yield impressive results. Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
Re: BGP to doom us all
In message <[EMAIL PROTECTED]>, "Barry Raveendran Greene " writes: > > >> The problem that sBGP is trying to solve is *authorization*, not >> identification. Briefly -- and please read the papers and the specs >> before flaming -- every originating AS would have a certificate chain >> rooted at their local RIR stating that they own a certain address >> block. If an ISP SWIPs a block to some customer, that ISP (which owns >> a certificate from the RIR for the parent block) would sign a >> certificate granting the subblock to the customer. The customer could >> then announce it via sBGP. >> >> The other part sBGP is that it provides a chain of signatures of the >> entire ASpath back to the originator. > >Now - show me an operational environment on the Internet were this authorizati >on >chain is _working_ today. RIRs and RADB do not count. As you mention before, >those databases and keeping them up to date are a "pulling teeth" exercise. It doesn't exist -- and we have routing problems, due mostly to carelessness, but... > >> Now -- there are clearly lots of issues here, including the fact that >> the the authoritative address ownership data for old allocations is, >> shall we say, a bit dubious. And the code itself is expensive to run, >> since it involves a lot of digital signatures and verifications, >> especially when things are thrashing because of a major backhoe hit. >> >> But -- given things like the AS7007 incident, and given the possibility >> -- probability? -- that it can happen again, can we afford to not do >> sBGP? > >AS 7007 can be solved with our existing tool set. > >As mentioned here and NANOGs in the past, our biggest problem are providers no >t >using the tools that they have to build incident resistance into today's >network. But not against more sophisticated variants. > >> My own opinion is that sophisticated routing attacks are the >> single biggest threat to the Internet. > >My opinion is that lazy operational practices are the single biggest threat to >the Internet. What's the point of building security and robustness into a syst >em >when people choose not to turn it on? > "Never attribute to malice what can be explained by incompetence". --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book)
RE: BGP to doom us all
> The problem that sBGP is trying to solve is *authorization*, not > identification. Briefly -- and please read the papers and the specs > before flaming -- every originating AS would have a certificate chain > rooted at their local RIR stating that they own a certain address > block. If an ISP SWIPs a block to some customer, that ISP (which owns > a certificate from the RIR for the parent block) would sign a > certificate granting the subblock to the customer. The customer could > then announce it via sBGP. > > The other part sBGP is that it provides a chain of signatures of the > entire ASpath back to the originator. Now - show me an operational environment on the Internet were this authorization chain is _working_ today. RIRs and RADB do not count. As you mention before, those databases and keeping them up to date are a "pulling teeth" exercise. > Now -- there are clearly lots of issues here, including the fact that > the the authoritative address ownership data for old allocations is, > shall we say, a bit dubious. And the code itself is expensive to run, > since it involves a lot of digital signatures and verifications, > especially when things are thrashing because of a major backhoe hit. > > But -- given things like the AS7007 incident, and given the possibility > -- probability? -- that it can happen again, can we afford to not do > sBGP? AS 7007 can be solved with our existing tool set. As mentioned here and NANOGs in the past, our biggest problem are providers not using the tools that they have to build incident resistance into today's network. > My own opinion is that sophisticated routing attacks are the > single biggest threat to the Internet. My opinion is that lazy operational practices are the single biggest threat to the Internet. What's the point of building security and robustness into a system when people choose not to turn it on?
Re: BGP to doom us all
> Cheap to buy, but the time for processing each certificate will > increase with the size of the routing table, and we just end up > replicating the problem of recalculating large routing tables, > but now with certification, no? no. you *really* may want to read up on sbgp before attempting to discuss its scaling qualities. randy
Re: BGP to doom us all
On Fri, 28 Feb 2003, Randy Bush wrote: :> I think the only problem with the comments is that they :> over-estimate the benefit of that level of security relative :> to the overhead it requires. : :crypto hardware has become cheap. Cheap to buy, but the time for processing each certificate will increase with the size of the routing table, and we just end up replicating the problem of recalculating large routing tables, but now with certification, no? -- batz
Re: BGP to doom us all
On Fri, 28 Feb 2003, Steven M. Bellovin wrote: :But -- given things like the AS7007 incident, and given the possibility :-- probability? -- that it can happen again, can we afford to not do :sBGP? My own opinion is that sophisticated routing attacks are the :single biggest threat to the Internet. Without sliding into a discussion about what our worst imaginable attack would be, how are they more of a threat than a worm that saturates links? I am interested in how you measure the threat of attacks against routing protocols against that of something like slammer, as I would think that routing problems would limit their own propagation much faster than say, the way slammer slowed itself down by saturating links. I am taking sophisticated routing attacks to mean specific protocol exploitation, instead of attacks on the devices themselves. I would even suspect that it is not possible for routing information to be scrambled in any widely propagated and irrepairable way, for similar reasons to why it can't be kept straight without constant updates. That is, the routes confusion will limit it's own propagation precisely because it may no longer know how to propagate itself. Or rather, the more valid paths valid routing information has, the more likely it will spread, no? I wonder how you could test that. Thanks, -- batz
Re: BGP to doom us all
> I think the only problem with the comments is that they > over-estimate the benefit of that level of security relative > to the overhead it requires. crypto hardware has become cheap. randy
Re: BGP to doom us all
On Fri, 28 Feb 2003, Randy Bush wrote: :actually, the article is not all that far off reality as i see it. :the exception being that the ietf has NOT been diligently pursuing :sBGP but rather a lot of the effort is going into a 3/4 hack being :pushed by vendor laziness. The comments in the article are accurate, but the choice of facts is conspicuous. This, given all the other horrible what-if scenarios out there. Also, publicly riffing on specific technical issues doesn't address the underlying causes of the problems. I think the only problem with the comments is that they over-estimate the benefit of that level of security relative to the overhead it requires. -- batz
Re: BGP to doom us all
In message <[EMAIL PROTECTED]>, Bruce Pinsky writes: > >Jim Deleskie wrote: >> >> http://news.com.com/2100-1009-990608.html?tag=fd_lede1_hed >> >> Seems the BGP will be the down fall of the internet, the sky is falling the >> sky is falling > > >What a crock of crap. Knowing who someone is doesn't stop them from causing >intentional or unintentional problems. In fact, authentication is more likely > The problem that sBGP is trying to solve is *authorization*, not identification. Briefly -- and please read the papers and the specs before flaming -- every originating AS would have a certificate chain rooted at their local RIR stating that they own a certain address block. If an ISP SWIPs a block to some customer, that ISP (which owns a certificate from the RIR for the parent block) would sign a certificate granting the subblock to the customer. The customer could then announce it via sBGP. The other part sBGP is that it provides a chain of signatures of the entire ASpath back to the originator. Now -- there are clearly lots of issues here, including the fact that the the authoritative address ownership data for old allocations is, shall we say, a bit dubious. And the code itself is expensive to run, since it involves a lot of digital signatures and verifications, especially when things are thrashing because of a major backhoe hit. But -- given things like the AS7007 incident, and given the possibility -- probability? -- that it can happen again, can we afford to not do sBGP? My own opinion is that sophisticated routing attacks are the single biggest threat to the Internet. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book)
Re: BGP to doom us all
> http://news.com.com/2100-1009-990608.html?tag=fd_lede1_hed actually, the article is not all that far off reality as i see it. the exception being that the ietf has NOT been diligently pursuing sBGP but rather a lot of the effort is going into a 3/4 hack being pushed by vendor laziness. randy
Re: BGP to doom us all
> What a crock of crap. Knowing who someone is doesn't stop them > from causing intentional or unintentional problems. In fact, > authentication is more likely to cause people to become > complacent wrt their filtering policies. Hey I've authenticated > that router so it's going to only send me correct routes. maybe you should actually read the sBGP specs before spouting off. randy
Re: BGP to doom us all
> Secure Garbage(tm). Definitely a great name for a rock band. -- Bruce Robertson, President/CEO +1-775-348-7299 Great Basin Internet Services, Inc. fax: +1-775-348-9412 http://www.greatbasin.net
Re: BGP to doom us all
On Fri, 28 Feb 2003, Jim Deleskie wrote: > http://news.com.com/2100-1009-990608.html?tag=fd_lede1_hed > > Seems the BGP will be the down fall of the internet, the sky is falling the > sky is falling Other than pending patents and a cool name Secure BGP, you still have the fundamental problem. Garbage In, Garbage Out. The only difference is now you have Secure Garbage(tm). There is a problem that needs to be solved. But like the whole micro-payments, SET, etc thing; if the solution is more complicated and more expensive than the alternatives; it won't get used no matter how "secure" it is.
Re: BGP to doom us all
On Fri, 28 Feb 2003, Bruce Pinsky wrote: :What a crock of crap. Knowing who someone is doesn't stop them from causing :intentional or unintentional problems. In fact, authentication is more likely :to cause people to become complacent wrt their filtering policies. Hey I've :authenticated that router so it's going to only send me correct routes. :Puleeeaaa... The authentication I suspect he is referring to, is certification of the routes themselves, not just mere peer authentication. However, given the recent academic popularity of attacks against routers, such as the phenolit OSPF exploit, Bindviews TCP ISN strange attractors, Tim Newshams ISN paper, some large vendors use of widely available hardware and/or operating systems, and others, it's worth being extra mindful of router security. Dashing off press releases about internet vulnerabilities is a bit like that cold fusion in a coffee cup incident. It harmed the credibility of all researchers and may have set back alot of other legitimate efforts. The technical solutions are pretty easy, almost everyone on the list understands them. Us cassandras in the security business just have to find a better way of making people more mindful of security in their day to day operations. Appeasing the media's thirst for broad and fearsome pronouncements doesn't help things. Unfortunately, this sort of mindfulness isn't so much taught as it must be learned, and so we are back to the operator clue issue. *sigh*. Mu. ;) -- batz
Re: BGP to doom us all
Jim Deleskie wrote: Bruce, I agree, while we all need to 'do the right thing' and only announce what we are suppose to, we also need to maintain the right level being paranoid to protect the networks we are responsible for. Right. And so while authentication and encryption of routing protocol exchanges is a necessary future to insure authenticity, it doesn't and won't absolve providers from the responsiblity of filtering both what they receive and what they transmit. And ideally, a goal of tying a route filtering mechanism to the authentication mechanism (i.e. adding authorization on top of authentication) would significantly reduce the burden and complexity of maintaining good route filters and thereby increase the chance that providers will implement them. == bep
RE: BGP to doom us all
Bruce, I agree, while we all need to 'do the right thing' and only announce what we are suppose to, we also need to maintain the right level being paranoid to protect the networks we are responsible for. -Jim -Original Message- From: Bruce Pinsky [mailto:[EMAIL PROTECTED] Sent: Friday, February 28, 2003 5:17 PM To: Jim Deleskie Cc: '[EMAIL PROTECTED]' Subject: Re: BGP to doom us all Jim Deleskie wrote: > > http://news.com.com/2100-1009-990608.html?tag=fd_lede1_hed > > Seems the BGP will be the down fall of the internet, the sky is falling the > sky is falling What a crock of crap. Knowing who someone is doesn't stop them from causing intentional or unintentional problems. In fact, authentication is more likely to cause people to become complacent wrt their filtering policies. Hey I've authenticated that router so it's going to only send me correct routes. Puleeeaaa... == bep
Re: BGP to doom us all
Jim Deleskie wrote: http://news.com.com/2100-1009-990608.html?tag=fd_lede1_hed Seems the BGP will be the down fall of the internet, the sky is falling the sky is falling What a crock of crap. Knowing who someone is doesn't stop them from causing intentional or unintentional problems. In fact, authentication is more likely to cause people to become complacent wrt their filtering policies. Hey I've authenticated that router so it's going to only send me correct routes. Puleeeaaa... == bep
BGP to doom us all
http://news.com.com/2100-1009-990608.html?tag=fd_lede1_hed Seems the BGP will be the down fall of the internet, the sky is falling the sky is falling