*) Filtering your customers using IRR is a requirement, however, it is not
a solution - in fact, in the demonstration, we registered the /24 prefix
we hijacked in IRR. RIRs need to integrate the allocation data with their
IRR data.
further clarification... [if this is obvious, just skip over the message].
IRR filters helps prevent *accidental* hijacking and *accidental* route
spillage. In that, they seem to do their job. I don't know why people
think that would help prevent a deliberate hijacking job.
I don't think there is enough "trust" in the IP allocation system from
the RIRs yet (trust anchors being the word of the week) to even
contemplate non-repudiation in advertisements yet.
We can go into lots of reasons why the Internet runs this way. I think
we can all agree 1) Its amazing it runs as well as it does, and 2) No
one has clearly articulated a financial reason for any large
organizations to significantly change their interconnection
methodologies over the current BCP [that exceeds the costs of doing so].
Until either of those assertions change, the status quo will essentially
remain.
Alex et al, I apologize if you already covered this in your preso...
One way to help mitigate the effects of this [as a user] is to keep all
of your conversation end points on the same network -- especially if you
run a VPN or similar -- and [rather than scan your traceroutes daily as
someone suggested] scan the IRRs daily to make sure no changes have been
entered for prefixes you care about.
Just some thoughts,
Deepak Jain