North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: AS8584 taking over the internet
- From: Curtis Villamizar
- Date: Thu Apr 23 19:28:10 1998
In message <email@example.com>, philip brid
> At 12:16 AM 4/10/98 +0000, Michael Shields wrote:
> >In article <firstname.lastname@example.org>,
> >philip bridge <email@example.com> 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 firstname.lastname@example.org www.ip-plus.ch
> PGP: DE78 06B7 ACDB CB56 CE88 6165 A73F B703
You might want to look at:
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:
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.