Ettiquette and rules regarding Hijacked ASN's or IP space?
So, with all this lifting the curtains on hijacked ASN's and ipblocks recently I have a few general question... 1) Should the rules be uniformly applied? 2) Should these rules be applied even when something 'bad' might happen? 3) How much involvment should ARIN have in enforcing these rules? Now, by 'rules' I mean: If you steal something you have to give it back, regardless of who you are. So, for an example, if I steal ASN 8143 (already stolen so its mute) and I'm 'a good guy', all I want to do is run a network no spam/abuse eminates from it, should I be subject to the 'witch hunt' that my fellow ASN stealer who does abuse/spam deals with? The same is asked for hijacked ip space. If I steal/hijack a large netblock, not from an active org so there is no 'damage' done, and I don't spam/abuse from it should I be compelled to return it also? Compelled in the same way that my brother stealer who spams/abuses is? I am not advocating one or the other, and to me the rules should apply to both groups (all theives treated equally)... I'm just curious as to the general thought on this subject. Additionally, how should ARIN go about verifying proper 'ownership' (that I am still me after all these years of 'inactivity'), how much is enough research on these issues? I know that at the ISP there is a measure of trust placed on the customer, and upstream/downstream, when it comes to ASN's and ip announcements. ARIN is in the same position as near as I can tell. They have to trust that the community both is trustworthy (to an extent) and conscientious. If there are bad actors out there that go to enough trouble they can make ASN's or ip blocks appear to be registered to themselves. There may be breadcrumbs of evidence if you look hard enough, perhaps there won't be. How hard should ARIN be looking at these issues and at specific instances? Should they apply their rules without prejudice? Sorry for the latenight not-completely-operational question :) but it seems as though there is some abmiguity in the current process/procedure/rules and I'd like to atleast start some discussion on the topic. Thanks. --Chris (chris@uu.net) ####################################################### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## #######################################################
Well as some of you know as of late I've been involved in investigations of number of hijacked ip blocks (about 40 and looking at more) and can tell you that for greater majority of companies (especially for companies that had /16s but even for companies that had /24) the records on internet do exist and not just in the whois - these are email messages in newsgroups, webpages, passing refernces, etc. In fact I'm able to trace what happened to original company that had ip block in 90% of the cases and based on that can tell if the company currently using the ip block had any relation with original or not - that is primary criteria to determine if ip block is hijcked. I'll release my finding on this list in week or two and you'll all be able to see this all. As far as rules being uniformerly applied - yes they should be, its not a matter of if the abuse exists from that ip block or not, its a matter of somebody using ip block that they are not authorized and is basicly theft or resources (if that company does not exist their resources should be back with ARIN - but this is actually rare, usually some other company buys the original and very few companies I'v seen just disappeared entirely). As for ARIN this question I expect would be raised on the next meeting and should be properly discussed at their ppml mailing list. I'm not sure how much they can or should do and don't want to give my recommendation about it right now. What I can tell you is that they are not proactive right now - for all the reports they received from me (and this is as I said almost 40 reports, the reports were very details about which company should have ip block and and case was quite well proved with materials from multiple sources) - ARIN has not tried to contact the companies, maximum they did is to restore original whois records before ip block got hijacked. I do hope that based on what they have seen ARIN will be a little more carefull about changes to whois and will require more documentation before doing change to particular old record - I personally think they should proactively investigate to confirm information similar to how I've been doing it before proceeding with changes. BTW: On particular case of AS8143 - it was hijacked, but it also appears that original company that had used this AS is not entirely dead, they are in process of restructuring and some of the use for that AS is valid. Basicly it appears hijacker took particular AS they just used for their announcements of hijacked ip space which were independent of other announcements of AS8143 which were ok. On Mon, 9 Jun 2003, Christopher L. Morrow wrote:
So, with all this lifting the curtains on hijacked ASN's and ipblocks recently I have a few general question...
1) Should the rules be uniformly applied? 2) Should these rules be applied even when something 'bad' might happen? 3) How much involvment should ARIN have in enforcing these rules?
Now, by 'rules' I mean:
If you steal something you have to give it back, regardless of who you are.
So, for an example, if I steal ASN 8143 (already stolen so its mute) and I'm 'a good guy', all I want to do is run a network no spam/abuse eminates from it, should I be subject to the 'witch hunt' that my fellow ASN stealer who does abuse/spam deals with? The same is asked for hijacked ip space. If I steal/hijack a large netblock, not from an active org so there is no 'damage' done, and I don't spam/abuse from it should I be compelled to return it also? Compelled in the same way that my brother stealer who spams/abuses is?
I am not advocating one or the other, and to me the rules should apply to both groups (all theives treated equally)... I'm just curious as to the general thought on this subject.
Additionally, how should ARIN go about verifying proper 'ownership' (that I am still me after all these years of 'inactivity'), how much is enough research on these issues? I know that at the ISP there is a measure of trust placed on the customer, and upstream/downstream, when it comes to ASN's and ip announcements. ARIN is in the same position as near as I can tell. They have to trust that the community both is trustworthy (to an extent) and conscientious. If there are bad actors out there that go to enough trouble they can make ASN's or ip blocks appear to be registered to themselves. There may be breadcrumbs of evidence if you look hard enough, perhaps there won't be. How hard should ARIN be looking at these issues and at specific instances? Should they apply their rules without prejudice?
Sorry for the latenight not-completely-operational question :) but it seems as though there is some abmiguity in the current process/procedure/rules and I'd like to atleast start some discussion on the topic.
Thanks.
--Chris (chris@uu.net) ####################################################### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## #######################################################
Fear leads to Hate, which leads to Evil, the way of the darkside ;) RIR's are not and should not be in the business of dictating what goes into the routing table, or what label is used on what goes into the routing table. I think part of the issue here is that to many providers don't filter what they receive from their BGP speaking peer. Its not that hard to build tools to drop known IANA reserved space packets, or even AS ranges. If we get into RIR's processing witch hunts, we run the strong and real risk of dropping real live users right off the net. Then that causes the risk for greater legal cost and exposure to happen. At the end of the day, RIR's make sure the bit strings are unique, and that reasonable costs for do that job are covered in registration fees. Its up to each provider to verify their BGP config and the data received from those peers. If this was easy everyone would or could do it. On Mon, Jun 09, 2003 at 05:12:26AM +0000, Christopher L. Morrow wrote:
So, with all this lifting the curtains on hijacked ASN's and ipblocks recently I have a few general question...
1) Should the rules be uniformly applied? 2) Should these rules be applied even when something 'bad' might happen? 3) How much involvment should ARIN have in enforcing these rules?
Now, by 'rules' I mean:
If you steal something you have to give it back, regardless of who you are.
So, for an example, if I steal ASN 8143 (already stolen so its mute) and I'm 'a good guy', all I want to do is run a network no spam/abuse eminates from it, should I be subject to the 'witch hunt' that my fellow ASN stealer who does abuse/spam deals with? The same is asked for hijacked ip space. If I steal/hijack a large netblock, not from an active org so there is no 'damage' done, and I don't spam/abuse from it should I be compelled to return it also? Compelled in the same way that my brother stealer who spams/abuses is?
I am not advocating one or the other, and to me the rules should apply to both groups (all theives treated equally)... I'm just curious as to the general thought on this subject.
Additionally, how should ARIN go about verifying proper 'ownership' (that I am still me after all these years of 'inactivity'), how much is enough research on these issues? I know that at the ISP there is a measure of trust placed on the customer, and upstream/downstream, when it comes to ASN's and ip announcements. ARIN is in the same position as near as I can tell. They have to trust that the community both is trustworthy (to an extent) and conscientious. If there are bad actors out there that go to enough trouble they can make ASN's or ip blocks appear to be registered to themselves. There may be breadcrumbs of evidence if you look hard enough, perhaps there won't be. How hard should ARIN be looking at these issues and at specific instances? Should they apply their rules without prejudice?
Sorry for the latenight not-completely-operational question :) but it seems as though there is some abmiguity in the current process/procedure/rules and I'd like to atleast start some discussion on the topic.
Thanks.
--Chris (chris@uu.net) ####################################################### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## #######################################################
On Monday, Jun 9, 2003, at 02:36 Canada/Eastern, John Brown wrote:
RIR's are not and should not be in the business of dictating what goes into the routing table, or what label is used on what goes into the routing table.
Just the other day I heard of a new customer of an ISP in Toronto who had requested transit for particular blocks. The numbers in question were registered to a tyre company in South Africa, and were now in use by a hosting company based in Sacramento, who now wanted the block announced in Toronto. The ISP in Toronto asked for an LOA, and got one, neatly presented on company letterhead, and accompanied by e-mail from the tech contact for the block confirming that the request to advertise the block was authorised. Is that enough justification to perform the announcement? Where exactly should the line be drawn? Someone made the point from the floor mike in Salt Lake City during the SBGP/SoBGP panel discussion that until there is an easy, manual way to answer the questions "should I accept this route from this AS" and "should I originate this route", no amount of crypto or automation is really going to help anything. Maybe some service akin to a credit check is required. "Hello, I have a request to accept an announcement of 203.97.0.0/17 from AS 4768." "That request is legitimate according to our records, here is your auth code." "Hello, my new customer with the following contact details has asked me to originate 203.167.0.0/18 from AS 9327." "We cannot confirm the legitimacy of that request, and the listed contact for 203.167.0.0/18 has been informed of your request." "Hello, my customer gave me the following pre-auth code together with a request to originate 203.97.128.0/17 on his behalf" "That pre-auth code matches the prefix, here is your auth code for this request." 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. Joe
On Mon, 9 Jun 2003, Joe Abley wrote:
The ISP in Toronto asked for an LOA, and got one, neatly presented on company letterhead, and accompanied by e-mail from the tech contact for the block confirming that the request to advertise the block was authorised.
Is that enough justification to perform the announcement? Where exactly should the line be drawn?
Unfortunately, probably not. How do they know it was company letterhead? Had they ever seen the company's letterhead before? How do they know I didn't just create that LOA and letterhead in OpenOffice?
Maybe some service akin to a credit check is required.
"Hello, I have a request to accept an announcement of 203.97.0.0/17 from AS 4768." "That request is legitimate according to our records, here is your auth code."
Trouble is, how do you/they know if both the space and ASN have been hijacked?
"Hello, my new customer with the following contact details has asked me to originate 203.167.0.0/18 from AS 9327." "We cannot confirm the legitimacy of that request, and the listed contact for 203.167.0.0/18 has been informed of your request."
The listed contact may not be who ARIN [or other local RIR] thinks it is.
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. 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. ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Monday, Jun 9, 2003, at 12:53 Canada/Eastern, jlewis@lewis.org wrote:
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.
The RIRs definitely hold some of the data that would be required to make educated pronouncements (although clearly not all of it). Note that I'm not talking about absolute accuracy here; as long as people are able to change companies, change their names, die, forge documentation and otherwise lie, there will always be fraud. What is needed is some trusted resource who can say "our best guess is that this is legitimate". At the moment there is no clear procedure for any ISP to follow to even get a best guess as to whether an advertisement should be accepted or not.
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.
I have met people who think that the existence of a route in the IRR is somehow demonstrable evidence that a route should be accepted. I'm not quite sure why they think that way. Joe
At the moment there is no clear procedure for any ISP to follow to even get a best guess as to whether an advertisement should be accepted or not.
What about requiring that a route appear in an RIR database period? Maybe that would be a good start. It's easy enough to do but virtually no one seems to do it. We've seen how lengthy The CIDR Report's list of unregistered (but nonetheless advertised) routes is -- why are these advertisements being accepted? This doesn't directly address hijacking, but it seems to me that there's no reason to spend time looking for old, unused, potentially hijackable address blocks if just about any ISP out there will accept your announcements of blocks that aren't even allocated. (Note: I'm not talking about IANA Reserved space.)
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
On Mon, Jun 09, 2003 at 06:06:50PM +0100, Stephen J. Wilcox wrote:
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.
Speaking as someone who is extremely annoyed by providers/peers/etc proxy registering IRR routes, I think a system which locks down registrations within specific prefixes to a specific maintainer, and an approval system for people who want to register blocks within your space, would be insanely useful. Someone please implement this for us US folks using irrd. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
On Mon, Jun 09, 2003 at 02:57:17PM -0400, Richard A Steenbergen wrote:
Speaking as someone who is extremely annoyed by providers/peers/etc proxy registering IRR routes, I think a system which locks down registrations within specific prefixes to a specific maintainer, and an approval system for people who want to register blocks within your space, would be insanely useful. Someone please implement this for us US folks using irrd.
See RIPE database. http://www.ripe.net/ripencc/faq/database/route-creation-checks.html Regards, Daniel
On Mon, 9 Jun 2003, John Brown wrote:
Fear leads to Hate, which leads to Evil, the way of the darkside ;)
RIR's are not and should not be in the business of dictating what goes into the routing table, or what label is used on what goes into the routing table.
Certainly not, but if the information we (isp's/Network operators) need to verify that our 'customer' has the right to route a block isn't correct or is easily subverted they have some responsibility there I'd think, right?
I think part of the issue here is that to many providers don't filter what they receive from their BGP speaking peer.
Hrm, I've heard this alot, and seen some other providers that clearly don't filter... but even more insidious are the ones that DO filter and rely on the information provided by an RIR to validate the 'ownership' of the blocks they build their filters for.
Its not that hard to build tools to drop known IANA reserved space packets, or even AS ranges.
that's not the issue here (or it wasn't the thrust of the original question atleast)
If we get into RIR's processing witch hunts, we run the strong and real risk of dropping real live users right off the net. Then that causes the risk for greater legal cost and exposure to happen.
Sure, this is true... so, how much is enough? and should the 'rules' still be applied equally, despite the fact that the nuns at Mother Jessica's Monestary who use Asn 8143 for upstream will get booted off the network because 8143 was hijacked?
At the end of the day, RIR's make sure the bit strings are unique, and that reasonable costs for do that job are covered in registration fees.
Its up to each provider to verify their BGP config and the data received from those peers.
Sure, you are announcing 196.1.1.0/24 and only that, fine, but are you allowed to announce that prefix? Are you "Centre for Monitoring Indian Economy" ?? Or is this your direct customer and you are just the sat-link provider for him?
If this was easy everyone would or could do it.
On Mon, Jun 09, 2003 at 05:12:26AM +0000, Christopher L. Morrow wrote:
So, with all this lifting the curtains on hijacked ASN's and ipblocks recently I have a few general question...
1) Should the rules be uniformly applied? 2) Should these rules be applied even when something 'bad' might happen? 3) How much involvment should ARIN have in enforcing these rules?
Now, by 'rules' I mean:
If you steal something you have to give it back, regardless of who you are.
So, for an example, if I steal ASN 8143 (already stolen so its mute) and I'm 'a good guy', all I want to do is run a network no spam/abuse eminates from it, should I be subject to the 'witch hunt' that my fellow ASN stealer who does abuse/spam deals with? The same is asked for hijacked ip space. If I steal/hijack a large netblock, not from an active org so there is no 'damage' done, and I don't spam/abuse from it should I be compelled to return it also? Compelled in the same way that my brother stealer who spams/abuses is?
I am not advocating one or the other, and to me the rules should apply to both groups (all theives treated equally)... I'm just curious as to the general thought on this subject.
Additionally, how should ARIN go about verifying proper 'ownership' (that I am still me after all these years of 'inactivity'), how much is enough research on these issues? I know that at the ISP there is a measure of trust placed on the customer, and upstream/downstream, when it comes to ASN's and ip announcements. ARIN is in the same position as near as I can tell. They have to trust that the community both is trustworthy (to an extent) and conscientious. If there are bad actors out there that go to enough trouble they can make ASN's or ip blocks appear to be registered to themselves. There may be breadcrumbs of evidence if you look hard enough, perhaps there won't be. How hard should ARIN be looking at these issues and at specific instances? Should they apply their rules without prejudice?
Sorry for the latenight not-completely-operational question :) but it seems as though there is some abmiguity in the current process/procedure/rules and I'd like to atleast start some discussion on the topic.
Thanks.
--Chris (chris@uu.net) ####################################################### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## #######################################################
On 6/9/2003 at 4:06 PM, "Christopher L. Morrow" <chris@UU.NET> wrote:
Sure, you are announcing 196.1.1.0/24 and only that, fine, but are you allowed to announce that prefix? Are you "Centre for Monitoring Indian Economy" ?? Or is this your direct customer and you are just the sat-link provider for him?
Being able to answer such 64,000-dollar-questions with authority is the issue ARIN's registry operations are facing, pass or fail. And you can take that literally: the recent hijacking events have put ARIN's rules, procedures and current registry data so much into question - it'll be (do || die) for them. The inherited Internic data going back almost 20 years doesn't help things. Indeed, I think that any and all legacy assignments should be purged, like the old Usenet, one by one. Some things that could be done: - contact all owners of IP space or ASNs with a demand to show legal, notarized paperwork showing their company's status as incorporated/active, and/or legal successor to the original registrant. Gotta use those 7 years of business records you're required to hold for something! - non-announced IP space with defunct contacts: -> reserved status, no AS may route those, until resolved per above - non-announced IP space with working contacts: email to POC every 30 days with the legal demands (email/paper mail). After 90 days: network set to 'reserved' status, no AS may announce these, until resolved per above. - announced IP space: announcing AS to be contacted in addition to POC for the network object. For AS's in violation, this shall mean that all upstream ASs as visible at popular exchange points should be contacted (at least once) as well. - announcing AS's that violate the 'do not announce' rule shall be dealt with in ways similar to the non-cooperating entities described in: http://www.arin.net/policy/2003_1.html - they will get their own network objects suspended. - complete publicly accessible list of all 'reserved' networks - the DNSBLs and private BGP blackhole feeds will do the rest. Wouldn't you want to know how quiet your inbox can be, when you have a BGP4 blackhole feed with SPEWS L1 as the source...
Hello Kia , In line On Mon, 9 Jun 2003, Kai Schlichting wrote:
On 6/9/2003 at 4:06 PM, "Christopher L. Morrow" <chris@UU.NET> wrote:
Sure, you are announcing 196.1.1.0/24 and only that, fine, but are you allowed to announce that prefix? Are you "Centre for Monitoring Indian Economy" ?? Or is this your direct customer and you are just the sat-link provider for him?
Being able to answer such 64,000-dollar-questions with authority is the issue ARIN's registry operations are facing, pass or fail. And you can take that literally: the recent hijacking events have put ARIN's rules, procedures and current registry data so much into question - it'll be (do || die) for them. The inherited Internic data going back almost 20 years doesn't help things. Indeed, I think that any and all legacy assignments should be purged, like the old Usenet, one by one. Some things that could be done:
- contact all owners of IP space or ASNs with a demand to show legal, notarized paperwork showing their company's status as incorporated/active, and/or legal successor to the original registrant. Gotta use those 7 years of business records you're required to hold for something! Already in progress . Using DNS lameness as start basis . I just got a note for an old ip-range I had promised the owner I'd keep active and forgot about over the years .
- non-announced IP space with defunct contacts: -> reserved status, no AS may route those, until resolved per above How would you go about admonishing hijackers (or what appears as a hijacker) OR the provider that has been given a letter of approval from the agency that appears to have the lease ? ... lots more questions in this vein ? For all of the items mentioned below . Just one foopah with a blackhole server & NOone is going to remain attached to it . That has been proven over & over again . If you can not implicitely trust the operator(s) of the blackhole(s) operators will etierh run their own of ignore the blackholes .
- non-announced IP space with working contacts: email to POC every 30 days with the legal demands (email/paper mail). After 90 days: network set to 'reserved' status, no AS may announce these, until resolved per above.
- announced IP space: announcing AS to be contacted in addition to POC for the network object. For AS's in violation, this shall mean that all upstream ASs as visible at popular exchange points should be contacted (at least once) as well.
- announcing AS's that violate the 'do not announce' rule shall be dealt with in ways similar to the non-cooperating entities described in: http://www.arin.net/policy/2003_1.html - they will get their own network objects suspended.
- complete publicly accessible list of all 'reserved' networks - the DNSBLs and private BGP blackhole feeds will do the rest. Wouldn't you want to know how quiet your inbox can be, when you have a BGP4 blackhole feed with SPEWS L1 as the source... -- +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network Engineer | P.O. Box 854 | Give me Linux | | babydr@baby-dragons.com | Coudersport PA 16915 | only on AXP | +------------------------------------------------------------------+
On Mon, 9 Jun 2003, Christopher L. Morrow wrote:
Sorry for the latenight not-completely-operational question :) but it seems as though there is some abmiguity in the current process/procedure/rules and I'd like to atleast start some discussion on the topic.
I'm not as interested in proving something was "stolen," but how do you prove you have a "legitimate" claim? To me, the difference is important, because the record keeping is so iffy you can question almost everything. For example, NSI messed up the creation date on my domain, changing to 2002 instead of the original date. How do I prove NSI screwed up (again)? Trust Verify Remember What is the role of IANA and the regional registries? IANA/RIR are the recordkeepers. You should be able to get a "certified" history of the records for an ASN, IP address, etc. Not just the "last" owner of record, but the equivalent of a transcript of the history of an ASN, IP address, etc. showing all the changes to the records since their original allocation. "Certified" doesn't mean IANA/RIR guarantees the "ownership" or that the person is who they claim to be. Like a college transcript, the user must authorize IANA/RIR to send the transcript directly to the ISP. I would expect IANA/RIR to charge a fee for the service. What about fraudlent transfers? This is difficult, because the crooks know all the loopholes. And often make bogus legal threats to keep their operation going. They share information about ISPs, but ISPs don't share information about bad customers. Eventually I think we are going to have to do something like banks, and report when accounts are closed for cause. And I don't mean vigilante black lists, but something that follows the law like Equifax or ChexSystems. If IANA/RIR recinds a transfer, as a recordkeeper, they would notify all the ISPs which had received a "transcript" involving the individual, ASN or IP address. As we've seen, most of these people are repeat offenders. What about mistakes? Mistakes happen. That's why I would prefer more information to make a decision rather than a binary accept/reject. It may be a legitimate transaction, but IANA/ARIN/RIPE/APNIC/LACNIC's records are out of date. With a complete transcript, I may contact the previous registrant and verify the information pending the update of the registry records. What proof should IANA/RIRs accept for a transfer? History is against us. The "rules" have changed over the years. Its difficult to say what is really legitimate. How do we reclaim abandoned space before a squatter moves in? What is acceptable legal proof of transfer of "ownership" of something some people say isn't an asset? How much detective work is IANA/RIR expected to do? How much should you have to pay for IANA/RIR to do that work? When is someone going to get prosecuted? Fraud, theft, conversion, etc.
participants (12)
-
Christopher L. Morrow -
Daniel Roesen -
jlewis＠lewis.org -
Joe Abley -
John Brown -
Kai Schlichting -
Mr. James W. Laferriere -
Richard A Steenbergen -
Sean Donelan -
Stephen J. Wilcox -
Terry Baranski -
william＠elan.net