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
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. Puleeeaaazzzz... ========== bep
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. :Puleeeaaazzzz... 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
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);
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 eng-int@network 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
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);
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
In message <3E5FDFC8.3000208@whack.org>, 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)
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
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?
In message <000301c2df98$1f5dcfe0$4413180a@cisco.com>, "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)
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?
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 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access
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
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
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
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
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
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.
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
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 neil@DOMINO.ORG
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
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.
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 *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
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 *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
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 <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
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
participants (18)
-
alex＠yuriev.com -
Andy Dills -
Barry Raveendran Greene -
batz -
Bruce Pinsky -
Bruce Robertson -
Daniel Karrenberg -
Jeffrey Meltzer -
Jim Deleskie -
jlewis＠lewis.org -
Mark Radabaugh -
Michael Hallgren -
neil＠DOMINO.ORG -
Randy Bush -
Richard A Steenbergen -
Rob Thomas -
Sean Donelan -
Steven M. Bellovin