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