Ettiquette and rules regarding Hijacked ASN's or IP space?
Stephen J. Wilcox
steve at telecomplete.co.uk
Mon Jun 9 17:06:50 UTC 2003
> > Since the RIRs contain the information required to answer those
> > questions, you'd expect them (or their data) to be involved in the
> > process of answering them.
>
> They really don't. Thus far, when space is assigned, the RIRs have no way
> to later authenticate that an organization using the space is the same one
> that they assigned it to.
RIPE at least uses a hierarchical authorisation scheme which means you cannot
register routes to an ASN and prefix you dont have authorisation on, where
authorisation on those blocks is passed down from supernets and superblocks
ultimately controlled by RIPE.
This means for me to add a route I effectively have proof from my authorisation
being granted by RIPE that this is mine to play with.
It doesnt entirely preclude hijacking by way of stealing authorisation but its
more difficult and they're making it tougher.
Why cant this be extended?
All my customers (who fall under RIPE) must have routes registered from their
ASN before I accept them. My peers and transits I trust a little more but dont
have to providing I'm willing to build filters.
> As for the current state of BGP authentication/sanity checking, I can say
> 2 of my 4 upstreams take whatever I put in the routing registry. The
> other two require an email be sent requesting prefix filter updates. I
> was just told by one, that they'll accept whatever I request, only
> questioning it if someone complains to them about it. The other, I
> haven't asked, but I assume they work similarly. On the bright side, all
> of them are at least filtering.
I suspect the filtering is more to protect them from route leaks than checking
your netiquette.
Bad :(
Steve
More information about the NANOG
mailing list