Home page logo
/

nanog logo nanog mailing list archives

Re: AS8584 taking over the internet
From: Curtis Villamizar <curtis () brookfield ans net>
Date: Thu, 23 Apr 1998 19:25:03 -0400


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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault