Re: AS8584 taking over the internet

[Curtis Villamizar <curtis () brookfield ans net>]

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