*) 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