In article <3.0.3.32.19980409083628.03cebbe8@mailhost.ip-plus.net>, philip bridge <bridge@ip-plus.net> wrote:
That is of course laudible. But the point has to be made that AS8584 is in Israel. In an environment when a small ISP in a small country can cause a lot of damage to the global Internet, a way has to be found to efficiently propogate this knowledge far and wide.
I don't understand this point. Would you have been happier if they were a small ISP in the United States? How about India? Finland? Why does it matter that AS8584 is in Israel? -- Shields, CrossLink.
On Fri, Apr 10, 1998 at 12:16:50AM +0000, Michael Shields wrote:
In article <3.0.3.32.19980409083628.03cebbe8@mailhost.ip-plus.net>, philip bridge <bridge@ip-plus.net> wrote:
That is of course laudible. But the point has to be made that AS8584 is in Israel. In an environment when a small ISP in a small country can cause a lot of damage to the global Internet, a way has to be found to efficiently propogate this knowledge far and wide.
I don't understand this point. Would you have been happier if they were a small ISP in the United States? How about India? Finland? Why does it matter that AS8584 is in Israel?
I believe that the implication was that: 1) they're not directly connected to any of the major _US_ backbones, and 2) they're on the other end of a fairly thin hose. And they can _still_ hose things this badly. This speaks not well of the architecture involved. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com
On Fri, Apr 10, 1998 at 12:16:50AM +0000, Michael Shields put this into my mailbox:
In article <3.0.3.32.19980409083628.03cebbe8@mailhost.ip-plus.net>, philip bridge <bridge@ip-plus.net> wrote:
That is of course laudible. But the point has to be made that AS8584 is in Israel. In an environment when a small ISP in a small country can cause a lot of damage to the global Internet, a way has to be found to efficiently propogate this knowledge far and wide.
I don't understand this point. Would you have been happier if they were a small ISP in the United States? How about India? Finland? Why does it matter that AS8584 is in Israel?
Not to speak for Mr. Bridge, but I believe the point is that if this can be done by someone in Israel, it can also be done by someone in say, Iraq. 'Mr. Hussein, can you tell us why your ISP is announcing the entire Internet?' 'Relax! Take a load off! Don't worry about it!' IOW, if some terrorist group manages to get set up where they can announce BGP, they can toy essentially with whatever they like, until people/their upstream gets a clue and installs filters. -dalvenjah -- Dalvenjah FoxFire (aka Sven Nielsen) "The weapon which causes the most Founder, the DALnet IRC Network damage to the Internet is the keyboard." e-mail: dalvenjah@dal.net WWW: http://www.dal.net/~dalvenjah/ whois: SN90 Try DALnet! http://www.dal.net/
IOW, if some terrorist group manages to get set up where they can announce BGP, they can toy essentially with whatever they like, until people/their upstream gets a clue and installs filters.
before we get too hysterical, it may be worth noting that to date the problems have been caused by lack of clue, not lack of ethics, morals, or empathy. not that this is reason less for caution, but it might guide our reaction towards the actual, as opposed to imagined, problems. randy
On Thu, Apr 09, 1998 at 08:51:00PM -0700, Randy Bush put this into my mailbox:
IOW, if some terrorist group manages to get set up where they can announce BGP, they can toy essentially with whatever they like, until people/their upstream gets a clue and installs filters.
before we get too hysterical, it may be worth noting that to date the problems have been caused by lack of clue, not lack of ethics, morals, or empathy. not that this is reason less for caution, but it might guide our reaction towards the actual, as opposed to imagined, problems.
Point taken. However, whether it's Joe Terrorist or Joe Cluebie that actually causes the problems, you're still going to get bombarded with calls like 'I can't get to www.playboy.com! the internet is broken! fix it!'. Intent doesn't really matter. The fact remains that it's possible for someone to screw up the rest of the internet. This doesn't mean that a quick decision on what to do about it needs to be reached; it does however mean that a *good* decision on what to do about it and how to prevent the problem needs to be reached. (My intent was not to panic, but to make aware.) -dalvenjah -- Dalvenjah FoxFire (aka Sven Nielsen) "Sir, your wit ambles well; Founder, the DALnet IRC Network it goes easily." e-mail: dalvenjah@dal.net WWW: http://www.dal.net/~dalvenjah/ whois: SN90 Try DALnet! http://www.dal.net/
Intent doesn't really matter. The fact remains that it's possible for someone to screw up the rest of the internet. This doesn't mean that a quick decision on what to do about it needs to be reached; it does however mean that a *good* decision on what to do about it and how to prevent the problem needs to be reached.
Look, it think its happened to all of us. Its 4am, your pager goes off and you have a message that someone in Boliva is announcing your /16. Or even worse, its 4am, you just got to sleep and your pager goes off and you announced someone in Boliva's /16. You wake up and fix it. Having strong filters on what routes you will and will not accept from your downstreams is important - so Joe Terrorist or Joe Halfaclue can't screw up and cause you trouble. Generally if the people doing the bulk of the route trading are managing things well this shouldn't be a problem and we'll all continue to live with the possibility that we'll be woken up in the middle of the night for minor and friendly glitches. -- Jason Weisberger Chief of Network Operations SoftAware, Inc. - 310/305-0275 "You may be whatever you resolve to be." -Thomas Jonathan "Stonewall" Jackson
On Thu, 9 Apr 1998, Jason L. Weisberger wrote:
Having strong filters on what routes you will and will not accept from your downstreams is important - so Joe Terrorist or Joe Halfaclue can't screw up and cause you trouble. Generally if the people doing the bulk of the route trading are managing things well this shouldn't be a problem and we'll all continue to live with the possibility that we'll be woken up in the middle of the night for minor and friendly glitches.
I agree that filters are useful. However, I think it is missing half of the problem if you simply assume that moving the configuration problem into the filters doesn't still remain a problem. For example, recently we added a new transit customer, and asked UUNet (who we have been very happy with despite this incident) to add their aggregates to their prefix filters for us. They did so, but a couple of weeks later we cleared the BGP session to make changes in our inbound route policy, and noticed we were getting almost no inbound traffic from them. Checking at the various looking glasses, it was obvious that UUNet was only accepting routes from us for this new transit customer (ie, they had replaced our existing filters with the new aggregates rather than appending them to the list). It took 14 hours to get them to understand what the problem was and to correct it. I'm not saying that filtering prefixes isn't a good safety net, but what I am saying is that you are simply moving the configuration problems to a different place. Granted, the scope of who is affected by an error is generally much smaller, but the root of the problem is manual configuration. We have never had a similar problem with MCI, and they build the filters from the IRR. As long as our route objects (and those of ASes we provide transit for) are correct, the filters on our BGP session are correct. John Tamplin Traveller Information Services jat@Traveller.COM 2104 West Ferry Way 205/883-4233x7007 Huntsville, AL 35801
At 11:51 PM -0400 4/9/98, Randy Bush wrote:
before we get too hysterical, it may be worth noting that to date the problems have been caused by lack of clue, not lack of ethics, morals, or empathy. not that this is reason less for caution, but it might guide our reaction towards the actual, as opposed to imagined, problems.
This isn't entirely true. I know of several cases (and they have been discussed on this list) where bogus routes have been announced with either malicious, unethical or immoral intentions. Case 1: bogus announcement to bring down Cyberpromo (this may have occured more than once). Case 2: bogus announcements of unallocated space to bypass spam filters, and avoid identification. Both of these cases were probably done to technically (at least nominally) clueful people who were generally authorized to advertise new routes. I suspect a real terrorist action would be dealt with more quickly. Perhaps the regularity of hosage means that a terrorist action wouldn't really have much effect, so perhaps there isn't too much to worry about. (terrorists don't attack trains that derail on a weekly basis anyway, and China Air has never had a terrorist threat...) But whatever the solution, it can probably be taken advantage of by the multitude of authorized people. What is needed is better auditing so that the people who make the mistakes, either honestly or on purpose, are punished appropriately for their mistakes. Punishment must work internationally. Perhaps what we need is a UN Internet Tribunal. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
At 12:16 AM 4/10/98 +0000, Michael Shields wrote:
In article <3.0.3.32.19980409083628.03cebbe8@mailhost.ip-plus.net>, philip bridge <bridge@ip-plus.net> wrote:
That is of course laudible. But the point has to be made that AS8584 is in Israel. In an environment when a small ISP in a small country can cause a lot of damage to the global Internet, a way has to be found to efficiently propogate this knowledge far and wide.
I don't understand this point. Would you have been happier if they were a small ISP in the United States? How about India? Finland? Why does it matter that AS8584 is in Israel?
No, no, no. The point I was trying to make is that doing a tutorial on the IRR toolset at a Nanog meeting will not propogate the knowledge about how to prevent these meltdowns with those tools far enough and wide enough. If you do not like the example of Israel, how about Switzerland, which is even smaller and happens to be where I live and work. How many multihomed, BGP-speaking ISPs do you think fly from Switzerland to Nanog meetings? The same goes for RIPE meetings or APNIC meetings. The techniques to prevent these meltdowns *have* to be easily implementable and well understood by the vast majority of ISPs, both big and small.
-- Shields, CrossLink.
______________________________________________________________ Philip Bridge ++41 31 688 8262 bridge@ip-plus.net www.ip-plus.ch PGP: DE78 06B7 ACDB CB56 CE88 6165 A73F B703
In message <3.0.3.32.19980414103400.03148348@mailhost.ip-plus.net>, philip brid ge writes:
At 12:16 AM 4/10/98 +0000, Michael Shields wrote:
In article <3.0.3.32.19980409083628.03cebbe8@mailhost.ip-plus.net>, philip bridge <bridge@ip-plus.net> wrote:
That is of course laudible. But the point has to be made that AS8584 is in Israel. In an environment when a small ISP in a small country can cause a lot of damage to the global Internet, a way has to be found to efficiently propogate this knowledge far and wide.
I don't understand this point. Would you have been happier if they were a small ISP in the United States? How about India? Finland? Why does it matter that AS8584 is in Israel?
No, no, no. The point I was trying to make is that doing a tutorial on the IRR toolset at a Nanog meeting will not propogate the knowledge about how to prevent these meltdowns with those tools far enough and wide enough. If you do not like the example of Israel, how about Switzerland, which is even smaller and happens to be where I live and work. How many multihomed, BGP-speaking ISPs do you think fly from Switzerland to Nanog meetings? The same goes for RIPE meetings or APNIC meetings. The techniques to prevent these meltdowns *have* to be easily implementable and well understood by the vast majority of ISPs, both big and small.
-- Shields, CrossLink.
______________________________________________________________ Philip Bridge ++41 31 688 8262 bridge@ip-plus.net www.ip-plus.ch PGP: DE78 06B7 ACDB CB56 CE88 6165 A73F B703
You might want to look at: http://www.iops.org/Documents/routing.html wrt to Dana Hude's comments: It is such accidents that reinforce the notion of per-prefix filtering. Of course if one changes one's IRR/RIPE DB/RADB entries to deliberately announce the world there could still be a problem with auto-generated accept policy. The solution to *that* is quality assurance of the database, an ongoing issue in RIPE DB WG at least. Even then how does one prevent someone coding 'ANY' for their announce policy when they should not? In the old NFSNET days human inspection of IRR entries assured quality but that's not practical anymore at a central registry. BTW- You can code ANY for your announce policy. What matters is what is coded in someone else's accept policy. On the broader topic of quality assurance of the database see: http://engr.ans.net/rps-auth/ and draft-ietf-rps-auth-00 The goals of the RPS WG are: RPSL - improve the ability to describe policy and aggregation so that a larger set of router configuration requirements can be met. authorization and authentication - provide an enforceable set of rules as to who can register what and provide the authentication support to verify the claimed "who". distributed registry - RSN draft-ietf-rps-dist-00 - distribute the database efficiently and in a way that doesn't comprise the authorization and authentication model. Likely to be added later is: query - provide a standardized query interface to make it easier to write tools that rely on being able to query the database. Curtis
On Thu, 23 Apr 1998, Curtis Villamizar wrote:
Hmmm... what else is there? http://www.iops.org/Documents/escalation.html Oh my! Look what it says at the end here... Point-of-contact information is required for each escalation level defined above. Telephone numbers and email addresses are required for each level. Information regarding appropriate protocols and methods for reliably making contact with each level should also be provided by the concerned organizations, including pager numbers, primary and alternate contacts, and information regarding preferred time windows, as appropriate. The contact information will be shared only among those providers who are IOPS members and who have subscribed to the process documented herein. While such sentiments may be appropriate in a private club, one wonders whether they should be found in documents from an organization that bills itself as the Internet Operators Organization. One also wonders whether a lot more could be accomplished simply by gathering the collected knowledge from the NANOG mailing list, NANOG meetings and other sources into a series of "Best Practices" documents. -- Michael Dillon - Internet & ISP Consulting http://www.memra.com - E-mail: michael@memra.com
In message <Pine.BSI.3.93.980423170325.27222C-100000@sidhe.memra.com>, Michael Dillon writes:
On Thu, 23 Apr 1998, Curtis Villamizar wrote:
Hmmm... what else is there?
http://www.iops.org/Documents/escalation.html
Oh my! Look what it says at the end here...
Point-of-contact information is required for each escalation level defined above. Telephone numbers and email addresses are required for each level. Information regarding appropriate protocols and methods for reliably making contact with each level should also be provided by the concerned organizations, including pager numbers, primary and alternate contacts, and information regarding preferred time windows, as appropriate.
The contact information will be shared only among those providers who are IOPS members and who have subscribed to the process documented herein.
While such sentiments may be appropriate in a private club, one wonders whether they should be found in documents from an organization that bills itself as the Internet Operators Organization.
One also wonders whether a lot more could be accomplished simply by gathering the collected knowledge from the NANOG mailing list, NANOG meetings and other sources into a series of "Best Practices" documents.
-- Michael Dillon - Internet & ISP Consulting http://www.memra.com - E-mail: michael@memra.com
Michael, There is nothing preventing an IOPS member from distributing contact information outside of IOPS and all of them do. All this says is that if an IOPS member discloses this information to IOPS it will be published by IOPS to other IOPS members who did the same but no further. Curtis
participants (10)
-
Curtis Villamizar -
Dalvenjah FoxFire -
Dean Anderson -
Jason L. Weisberger -
Jay R. Ashworth -
John A. Tamplin -
Michael Dillon -
philip bridge -
Randy Bush -
shields＠crosslink.net