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 # in a route attestation, to reduce the need to generate different UPDATEs for each peer, so long as the UPDATE would otherwise be the same. We have not explored the implications of this in detail, but it does suggest a possible way to reduce
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
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
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 *allocationassignment* 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
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: 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 URL: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
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
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
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
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
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: 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: 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: BGP to doom us all
From: Avi Freedman snip : 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
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
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
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: 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: 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, 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
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 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: 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
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
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: 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
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
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
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
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
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
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
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
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, 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
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
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
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
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
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
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, 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
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
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
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!
