Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17
Corporate identity theft is a simple ploy which may be used to illicitly obtain valuable IPv4 address space. Actual use of this fradulent ploy was first described publicly in April, 2008 (https://wapo.st/2YLEhlZ). Quite simply, a party bent on undertaking this ploy may just search the publicly available IP block WHOIS records, looking for abandoned and unrouted IPv4 address blocks belonging to companies or organizations which no longer exist. Upon finding any such, the thief may simply undertake to formally register, with relevant government authorities, a new corporate entity with the same or a very similar name as the now defunct entity that is still listed in the WHOIS records as the registrant of the coveted IPv4 address block(s). Note that so-called "legacy" address blocks, i.e. those which were assigned prior to the formation of ARIN in early 1997, are especially prized by IPv4 address thieves because such blocks may be less subject to effective control or regulation by Regional Internet Registries. Publicly available evidence strongly suggests that a corporate identity theft has occurred with respect to a former Delaware corporate entity known as Azuki, LLC and also with respect to its valuable legacy IPv4 address block, 216.179.128.0/17. The corporate search function of the Delaware Secretary of State's web site may be used to obtain records relevant to corporate entities registered in Delaware: https://icis.corp.delaware.gov/Ecorp/EntitySearch/NameSearch.aspx At present, the Delaware SoS's web site indicates that there are or have been two different corporate entities, both named Azuki, LLC, that have been registered in the State of Delaware. The file numbers for these entities are 2810116 and 4751384. The former entity was first registered in Delaware on or about 10/20/1997. It's current operating status cannot be known without paying a fee. My own personal speculation is that it most likely ceased operation well more than a decade ago. The latter entity was registered in Delaware on or about 11/9/2009. According to the current live ARIN WHOIS record for the 216.179.128.0/17 address block (NET-216-179-128-0-1), this block was first allocated by ARIN to Azuki, LLC on or about 1999-01-07. Quite obviously, this assignment must have been made by ARIN to the original 1997 Azuki, LLC because the one that was registered in Delaware in 2009 did not yet exist at that time. Nontheless the mailing address currently present in the ARIN WHOIS record for the 216.179.128.0/17 IPv4 address block, and the one which is also present in the ARIN WHOIS record for the 2009 vintage ASN, AS13389 (Azuki, LLC), i.e. 3500 South DuPont Hwy, Dover, DE, 19901, matches exactly with the address given in Delaware corporate records for the particular Azuki, LLC that was registered in Delaware in 2009. (The corporate address that is still on file in Delaware for the original 1997 Azuki, LLC is located in a different Delaware city altogether.) These evident inconsistancies, by themselves, are strongly indicative of a probable case of corporate identity theft. Additional indicators are however also present in this case. In particular, the contact email address for both the Azuki, LLC ASN (AS13389) and the Azuki, LLC IPv4 address block (216.179.128.0/17), i.e. tech_dep (at) azukinet.com, make reference to the azukinet.com domain which was, according to the relevant GoDaddy WHOIS record, registered anew on or about 2011-05-12, some twelve years -after- the original assignment, by ARIN, of the 216.179.128.0/17 block to Azuki, LLC. The absence of evidence of the contnuous registration of this one and only contact domain name since the original 1999 assignment, by ARIN, of the 216.179.128.0/17 address block also tends to support the theory that this valuable address block has been illicitly and perhaps illegally appropriated by some party or parties unknown, and specifically via the fradulent ruse of a corporate identity theft. Quite simply, my theory is that following the demise of the original Azuki, LLC, sometime in the 2000s, some enterprising crook registered the domain name azukinet.com in order to successfully impersonate the actual and original Azuki, LLC, specifically when interacting with ARIN staff members. This simple ruse appears to have worked successfully for its intended purpose. Additionally, attempts to call the contact phone number for Azuki, LLC, (+1-213-304-6809) as currently listed in both the relevant ASN and the relevant IP block WHOIS records, during normal business hours, Eastern Daylight Time, yield only an anonymous answering machine recording. (The recorded message does not even state the company name.) This is yet another indicator of possible deliberate deception. Last but not least, the widely-respected Spamhaus anti-spam organization has had the entirety of the 216.179.128.0/17 block listed on its anti-spam SBL list since 2019-06-08, i.e. two full months, dating backwards from today: https://www.spamhaus.org/sbl/query/SBL103083 This listing, together with additional data from passive DNS and reverse DNS scans suggest that the 216.179.128.0/17 block has been and is being used for less than entirely admirable purposes. This is yet another persuasive indicator of the possible/probable theft of the block. I will shortly be informing both hostmaster (at) arin.net and also the folks at Spamhaus of all of the above factual findings. I did however want to share this information also with the NANOG community. Some or all of you may wish to drop all packets from addresses currently announced by AS13389, and/or may wish to encourage the direct peers of AS13389 to review those peering arrangements. Of course, my exposition of all of the above facts and indicators may perhaps also serve to further educate members of the community regarding what to look for when and if suspicions are cast upon a particular IP block or ASN. In the 2008 case referenced above, which involved self-evident corporate identity theft as a ruse to steal IPv4 address assets, ARIN apparently elected not to actively seek the involvement of law enforcement, even though the multiple clearly fraudulent actions undertaken in that case were altogether apparent and were clearly perpetrated quite deliberately and directly against ARIN. In multiple more recent instances in which ARIN has, allegedly, been targeted and defrauded, ARIN appears to have become more proactive in seeking the involvement of criminal law enforcement. Specifically, in addition to the well-publicized, notorious, and ongoing "Micfo" case, a less well reported federal criminal case (3:18-cr-04683-GPC), filed the Southern District of California last year, is currently ongoing. This case also and likewise attempts to hold to account, criminally, a different set of actors who also are alleged to have perpetrated a rather elaborate fraud against ARIN for the purpose of illicitly obtaining control over a number of IPv4 address blocks. Personally, I am gratified that ARIN is nowadays taking this more forward leaning posture towards those criminal actors who would attempt to use fraud and deception to surreptitiously obtain IPv4 address blocks. I do also hope that if the tenative conclusions of this public report are borne out by subsequent investigation, that ARIN will again and likewise seek an appropriate response from elements of the criminal law enforcement community. We cannot have and should not have these kinds of events happening again and again. Some appropriate deterrence against ALL of these kinds of crooks is therefore no longer optional. Regards, rfg
Thought you may find these connections with the 3500 South DuPont Hwy, Dover, DE, 19901 address interesting. https://offshoreleaks.icij.org/nodes/14014038 Thank you, Kevin McCormick -----Original Message----- From: NANOG <nanog-bounces@nanog.org> On Behalf Of Ronald F. Guilmette Sent: Thursday, August 8, 2019 2:54 PM To: nanog@nanog.org Subject: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17 Corporate identity theft is a simple ploy which may be used to illicitly obtain valuable IPv4 address space. Actual use of this fradulent ploy was first described publicly in April, 2008 (https://wapo.st/2YLEhlZ). Quite simply, a party bent on undertaking this ploy may just search the publicly available IP block WHOIS records, looking for abandoned and unrouted IPv4 address blocks belonging to companies or organizations which no longer exist. Upon finding any such, the thief may simply undertake to formally register, with relevant government authorities, a new corporate entity with the same or a very similar name as the now defunct entity that is still listed in the WHOIS records as the registrant of the coveted IPv4 address block(s). Note that so-called "legacy" address blocks, i.e. those which were assigned prior to the formation of ARIN in early 1997, are especially prized by IPv4 address thieves because such blocks may be less subject to effective control or regulation by Regional Internet Registries. Publicly available evidence strongly suggests that a corporate identity theft has occurred with respect to a former Delaware corporate entity known as Azuki, LLC and also with respect to its valuable legacy IPv4 address block, 216.179.128.0/17. The corporate search function of the Delaware Secretary of State's web site may be used to obtain records relevant to corporate entities registered in Delaware: https://icis.corp.delaware.gov/Ecorp/EntitySearch/NameSearch.aspx At present, the Delaware SoS's web site indicates that there are or have been two different corporate entities, both named Azuki, LLC, that have been registered in the State of Delaware. The file numbers for these entities are 2810116 and 4751384. The former entity was first registered in Delaware on or about 10/20/1997. It's current operating status cannot be known without paying a fee. My own personal speculation is that it most likely ceased operation well more than a decade ago. The latter entity was registered in Delaware on or about 11/9/2009. According to the current live ARIN WHOIS record for the 216.179.128.0/17 address block (NET-216-179-128-0-1), this block was first allocated by ARIN to Azuki, LLC on or about 1999-01-07. Quite obviously, this assignment must have been made by ARIN to the original 1997 Azuki, LLC because the one that was registered in Delaware in 2009 did not yet exist at that time. Nontheless the mailing address currently present in the ARIN WHOIS record for the 216.179.128.0/17 IPv4 address block, and the one which is also present in the ARIN WHOIS record for the 2009 vintage ASN, AS13389 (Azuki, LLC), i.e. 3500 South DuPont Hwy, Dover, DE, 19901, matches exactly with the address given in Delaware corporate records for the particular Azuki, LLC that was registered in Delaware in 2009. (The corporate address that is still on file in Delaware for the original 1997 Azuki, LLC is located in a different Delaware city altogether.) These evident inconsistancies, by themselves, are strongly indicative of a probable case of corporate identity theft. Additional indicators are however also present in this case. In particular, the contact email address for both the Azuki, LLC ASN (AS13389) and the Azuki, LLC IPv4 address block (216.179.128.0/17), i.e. tech_dep (at) azukinet.com, make reference to the azukinet.com domain which was, according to the relevant GoDaddy WHOIS record, registered anew on or about 2011-05-12, some twelve years -after- the original assignment, by ARIN, of the 216.179.128.0/17 block to Azuki, LLC. The absence of evidence of the contnuous registration of this one and only contact domain name since the original 1999 assignment, by ARIN, of the 216.179.128.0/17 address block also tends to support the theory that this valuable address block has been illicitly and perhaps illegally appropriated by some party or parties unknown, and specifically via the fradulent ruse of a corporate identity theft. Quite simply, my theory is that following the demise of the original Azuki, LLC, sometime in the 2000s, some enterprising crook registered the domain name azukinet.com in order to successfully impersonate the actual and original Azuki, LLC, specifically when interacting with ARIN staff members. This simple ruse appears to have worked successfully for its intended purpose. Additionally, attempts to call the contact phone number for Azuki, LLC, (+1-213-304-6809) as currently listed in both the relevant ASN and the relevant IP block WHOIS records, during normal business hours, Eastern Daylight Time, yield only an anonymous answering machine recording. (The recorded message does not even state the company name.) This is yet another indicator of possible deliberate deception. Last but not least, the widely-respected Spamhaus anti-spam organization has had the entirety of the 216.179.128.0/17 block listed on its anti-spam SBL list since 2019-06-08, i.e. two full months, dating backwards from today: https://www.spamhaus.org/sbl/query/SBL103083 This listing, together with additional data from passive DNS and reverse DNS scans suggest that the 216.179.128.0/17 block has been and is being used for less than entirely admirable purposes. This is yet another persuasive indicator of the possible/probable theft of the block. I will shortly be informing both hostmaster (at) arin.net and also the folks at Spamhaus of all of the above factual findings. I did however want to share this information also with the NANOG community. Some or all of you may wish to drop all packets from addresses currently announced by AS13389, and/or may wish to encourage the direct peers of AS13389 to review those peering arrangements. Of course, my exposition of all of the above facts and indicators may perhaps also serve to further educate members of the community regarding what to look for when and if suspicions are cast upon a particular IP block or ASN. In the 2008 case referenced above, which involved self-evident corporate identity theft as a ruse to steal IPv4 address assets, ARIN apparently elected not to actively seek the involvement of law enforcement, even though the multiple clearly fraudulent actions undertaken in that case were altogether apparent and were clearly perpetrated quite deliberately and directly against ARIN. In multiple more recent instances in which ARIN has, allegedly, been targeted and defrauded, ARIN appears to have become more proactive in seeking the involvement of criminal law enforcement. Specifically, in addition to the well-publicized, notorious, and ongoing "Micfo" case, a less well reported federal criminal case (3:18-cr-04683-GPC), filed the Southern District of California last year, is currently ongoing. This case also and likewise attempts to hold to account, criminally, a different set of actors who also are alleged to have perpetrated a rather elaborate fraud against ARIN for the purpose of illicitly obtaining control over a number of IPv4 address blocks. Personally, I am gratified that ARIN is nowadays taking this more forward leaning posture towards those criminal actors who would attempt to use fraud and deception to surreptitiously obtain IPv4 address blocks. I do also hope that if the tenative conclusions of this public report are borne out by subsequent investigation, that ARIN will again and likewise seek an appropriate response from elements of the criminal law enforcement community. We cannot have and should not have these kinds of events happening again and again. Some appropriate deterrence against ALL of these kinds of crooks is therefore no longer optional. Regards, rfg
Further investigation of this case obliges me to post the following correction and retraction. Additional evidence now strongly suggests that the 216.179.128.0/17 IP address block has NOT been "stolen" as I had suggested yesterday. I simply mis-read the ARIN historical registration ("WhoWas") data with repect to this block. In fact, the ARIN historical "WhoWas" registration data for this block indicates that when the block was first assigned, by ARIN... which the historical WhoWas records show as occuring on 06-24-2002... the block was assigned to a Southern California company named HHSI, Inc. Records available on the California Secretary of State's web site indicate that this company was first registered with the State of California 02/11/2002. Oddly, some seven years would pass after the registration of this California corporation before any documents were filed with California which would designate any officers of the company. On 03/02/2009 however a filing was made indicating the President of the company was a gentleman named Koji Ban. Additional corporate filings in subsequent years indicate that both Mr. Ban and the company, HHSI, Inc. were located at 20 Arches, Irvine, CA 92603. On or about 02-17-2010 the public WHOIS record for the 216.179.128.0/17 block was changed so that instead of designating HHSI, Inc. (California) as the block's registrant, the WHOIS record for the block would henceforth say instead that the registrant of the block was the 2009 vintage Delaware LLC called Azuki, LLC. Unfortunately, we cannot read too much into this change that was made to the block's public-facing WHOIS record. Neither the new WHOIS info nor even the old WHOIS info can be used to reliably infer who or what is the legitimate registrant of the block at any point in time. This is because ARIN, like all of the other Regional Internet Registries, allows registrants to put essentially any bovine excrement they desire into their public-facing WHOIS records. (And, it should be noted, the man behind the recent large scale "Micfo" fraud apparently availed himself of this exact opportunity far subterfuge, in spades.) Regardless, the available records suggest that there are only two likely possibilities in this case: 1) On or about 02-17-2010 HHSI, Inc. (California) transfered the registration of the 216.179.128.0/17 block from itself to the 2009 vintage Delaware entity Azuki, LLC. If this is what happened, then it is likely that the transfer was performed in violation of the applicable ARIN trasfer policy that was in force at the time. (Azuki, LLC did not simply buy-out HHSI, Inc., lock, stock, and barrel in 2010. California records show that HHSI, Inc. continued to be an active California corporation until at least 02/12/2014, and probably well beyond that date.) 2) Alternatively, on or about 02-17-2010 HHSI, Inc. (California) simply altered what would henceforth appear in the public-facing WHOIS record for the the 216.179.128.0/17 block to make it appear... to everyone except ARIN staff, who knew better... that the block was now registered to Azuki, LLC in Delaware. Only ARIN staff can tell us which of these possibilities actually applies. But due to ARIN's strict adherence to contractual confidentiality with respect to all of their resource holders, I do not anticipate that ARIN will actually provide any clarity on this case anytime soon. To summarize, either the block was transferred in 2010 in violation of ARIN's own transfer policy or else the information that we have all been looking at in this block's WHOIS record since 02-17-2010 is and has been nothing other than a very deliberate and bald-faced lie. There is no third option. Regardless of which of the two possible scenarios applies, it is a dead certainty that the registration of the 216.179.128.0/17 block was indeed transferred away from HHSI, Inc. at some point in time, and in a manner that most probably did not comport with applicable ARIN transfer restrictions in place at the time. I say this without fear of contradiction because the State of California currently lists HHSI, Inc. as "suspended". Legally speaking, it no longer exists. It cannot therefore still be a valid contractual counterparty, with ARIN, or with respect to the registration of *any* ARIN-administered resources. All of this ambiguity, and all of these crooked deception games are enabled and materially aided and abetted by the disastrous interplay of two longstanding policies that are and have been in force, for many many years, both at ARIN an also at all of the other RIRs, namely: *) Excessive anal retentiveness with respect to corporate confidentiality which deprives the public at large from even knowing even so much as the accurate and correct legal names of resource holders. *) Policies which permit resource holders to place any arbitrary garbage they desire into their associated public-facing WHOIS records, without there being any vetting at all of that information by the RIRs. I am not now and never have been a big fan of ICANN, but to ICANN"s credit, it at least had the good sense to recognize, years ago, that crooks are in fact present on the Internet, and that many of them have no qualms at all about putting deliberately misleading garbage into the WHOIS records for their registered domain names. As a result, ICANN developed both policies and procedures, feeble though they may be, to try to respond to this perennial and ongoing problem. I do wonder what sort of catastrophy it is going to take before the Regional Internet Registries likewise take at least some affirmative steps to address the fact that -their- WHOIS records are now also (and provably) contaminated with unreliable garbage, put there deliberately by various flavors of Internet miscreants intent on harming the rest of us honest netizens. Regards, rfg
On 9 Aug 2019, at 4:09 PM, Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
... Unfortunately, we cannot read too much into this change that was made to the block's public-facing WHOIS record. Neither the new WHOIS info nor even the old WHOIS info can be used to reliably infer who or what is the legitimate registrant of the block at any point in time. This is because ARIN, like all of the other Regional Internet Registries, allows registrants to put essentially any bovine excrement they desire into their public-facing WHOIS records.
Ronald - That is not the case – ARIN confirms the legal status of organizations receiving number resources.
(And, it should be noted, the man behind the recent large scale "Micfo" fraud apparently availed himself of this exact opportunity far subterfuge, in spades.)
As previously noted on this list, such was only possible because of the use of falsely notarized documents.
Regardless, the available records suggest that there are only two likely possibilities in this case:
1) On or about 02-17-2010 HHSI, Inc. (California) transfered the registration of the 216.179.128.0/17 block from itself to the 2009 vintage Delaware entity Azuki, LLC. If this is what happened, then it is likely that the transfer was performed in violation of the applicable ARIN trasfer policy that was in force at the time. (Azuki, LLC did not simply buy-out HHSI, Inc., lock, stock, and barrel in 2010. California records show that HHSI, Inc. continued to be an active California corporation until at least 02/12/2014, and probably well beyond that date.)
2) Alternatively, on or about 02-17-2010 HHSI, Inc. (California) simply altered what would henceforth appear in the public-facing WHOIS record for the the 216.179.128.0/17 block to make it appear... to everyone except ARIN staff, who knew better... that the block was now registered to Azuki, LLC in Delaware.
Only ARIN staff can tell us which of these possibilities actually applies. But due to ARIN's strict adherence to contractual confidentiality with respect to all of their resource holders, I do not anticipate that ARIN will actually provide any clarity on this case anytime soon.
That is easy to address: submit a fraud request, and it will be reviewed and corrected if it was done fraudulently. Thanks! /John John Curran President and CEO American Registry for Internet Numbers
Seems like submitting a fraud request to ARIN is more effective than writing a novel and sending it to NANOG, and doesn't require the latter... On Mon, Aug 12, 2019, 3:16 PM John Curran <jcurran@arin.net> wrote:
On 9 Aug 2019, at 4:09 PM, Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
... Unfortunately, we cannot read too much into this change that was made to the block's public-facing WHOIS record. Neither the new WHOIS info nor even the old WHOIS info can be used to reliably infer who or what is the legitimate registrant of the block at any point in time. This is because ARIN, like all of the other Regional Internet Registries, allows registrants to put essentially any bovine excrement they desire into their public-facing WHOIS records.
Ronald -
That is not the case – ARIN confirms the legal status of organizations receiving number resources.
(And, it should be noted, the man behind the recent large scale "Micfo" fraud apparently availed himself of this exact opportunity far subterfuge, in spades.)
As previously noted on this list, such was only possible because of the use of falsely notarized documents.
Regardless, the available records suggest that there are only two likely possibilities in this case:
1) On or about 02-17-2010 HHSI, Inc. (California) transfered the registration of the 216.179.128.0/17 block from itself to the 2009 vintage Delaware entity Azuki, LLC. If this is what happened, then it is likely that the transfer was performed in violation of the applicable ARIN trasfer policy that was in force at the time. (Azuki, LLC did not simply buy-out HHSI, Inc., lock, stock, and barrel in 2010. California records show that HHSI, Inc. continued to be an active California corporation until at least 02/12/2014, and probably well beyond that date.)
2) Alternatively, on or about 02-17-2010 HHSI, Inc. (California) simply altered what would henceforth appear in the public-facing WHOIS record for the the 216.179.128.0/17 block to make it appear... to everyone except ARIN staff, who knew better... that the block was now registered to Azuki, LLC in Delaware.
Only ARIN staff can tell us which of these possibilities actually applies. But due to ARIN's strict adherence to contractual confidentiality with respect to all of their resource holders, I do not anticipate that ARIN will actually provide any clarity on this case anytime soon.
That is easy to address: submit a fraud request, and it will be reviewed and corrected if it was done fraudulently.
Thanks! /John
John Curran President and CEO American Registry for Internet Numbers
In message <CA+FDdDQ3vBm_=j2GjdHRT4evh_5yz8Lzg2bKTaTErBWpgavp=A@mail.gmail.com> Ross Tajvar <ross@tajvar.io> wrote:
Seems like submitting a fraud request to ARIN is more effective than writing a novel and sending it to NANOG, and doesn't require the latter...
As noted in my immediately prior posting, ARIN's careful adjudication of this or any other possible case of fraud could take weeks or even months. And even if, after careful and thoughtful deliberation, ARIN concludes that there is indeed something wrong here, ARIN has neither the power nor the authority to tell anyone how to configure their routers, and thus, any decision or conclusion made by ARIN, regarding this or any other case of possible fraud, will have no immediate effect on the flow of bad packets. Regards, rfg P.S. I do apologize for my verbosity. As the late Carl Sagan often said, extraordinary claims require extraordinary evidence. I made the extraordinary claim, on this public mailing list, that -something- fradulent had gone on with respect to the 216.179.128.0/17 block which has resulted in the WHOIS record for that bearing little or no relationship to actual reality. Having made the claim, I felt a duty to explain and to provide the evidence, not in 140 characters, but in detail.
On Mon, Aug 12, 2019 at 04:11:00PM -0400, Ross Tajvar wrote:
Seems like submitting a fraud request to ARIN is more effective than writing a novel and sending it to NANOG, and doesn't require the latter...
But if he didn't fully document his assertion(s), then he would be faced with a plethora of replies decrying the lack of substantiating evidence. Better to lay the case out in detail so that everyone can see the work and so that anyone who cares to can check it for themselves. And -- given Ron's long history of thorough documentation -- there are some of us who are willing to take his word for it and make operational decisions based on what he reports, independent of what ARIN decides to do or not do, or when it decides to do it. ---rsk
In message <D9973D64-91AB-4380-B5E8-DEE173726CC0@arin.net>, John Curran <jcurran@arin.net> wrote:
On 9 Aug 2019, at 4:09 PM, Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
... Unfortunately, we cannot read too much into this change that was made to the block's public-facing WHOIS record. Neither the new WHOIS info nor even the old WHOIS info can be used to reliably infer who or what is the legitimate registrant of the block at any point in time. This is because ARIN, like all of the other Regional Internet Registries, allows registrants to put essentially any bovine excrement they desire into their public-facing WHOIS records.
That is not the case – ARIN confirms the legal status of organizations receiving number resources.
This is NOT the message that I got from our recent discussion of the giant Micfo fraud on the ARIN Public Policy Mailing List. When I raised questions about why various of the Micfo phoney baloney shell companies has block with WHOIS records saying they were located in states that they were obviously not located in, I believe that you said that once a black has been allocated, by ARIN, to some (properly vetted) entity, that after that point in time, the entity could -change- the relevant WHOIS record to say any bloody thing it wanted, and that such -changes- to ARIN WHOIS records are not vetted in any way. If I got the Wrong Impression from your prior statements, then by all means, please do correct me. And then please do explain why several of the Micfo phony shell companies did in fact have WHOIS records for ARIN- issued IPv4 space that gave street addreses in states where none of these phony shell companies were actually registered to do business.
(And, it should be noted, the man behind the recent large scale "Micfo" fraud apparently availed himself of this exact opportunity far subterfuge, in spades.)
As previously noted on this list, such was only possible because of the use of falsely notarized documents.
I -do- understand that the fradulent documents that were originally presented to you/ARIN provided information indicating that the phoney Micfo shell companies -did- actually exist in -some- state (Delaware?), and that ARIN -did- verify, to the best of its ability, that those companies -did- exist, legally spekaing, in their originally declared home state(s). But that fact is just skirting the real issue here, which is the question of whether or not ARIN even looks at -changes_ that a registrant may make to the WHOIS records (e.g. for IPv4 blocks) -after- those blocks have been assigned. It appears from where I am sitting that ARIN dos not do so. And thus, I stand by my comment that a registrant -can- in fact put any bloody nonsense they want into their WHOIS records, at least as long as they do it via -changes- and not in the original/initial WHOIS records.
Regardless, the available records suggest that there are only two likely possibilities in this case:
{trimmed} 1) 216.179.128.0/17 was transferred in violation of ARIN policy.
2) The current WHOIS for 216.179.128.0/17 is simply fradulent.
That is easy to address: submit a fraud request, and it will be reviewed and corrected if it was done fraudulently.
I would do that, but for the following four things: 1) ARIN is not the Internet Police and has no power to affect routing decisions of anybody. 2) Getting the info out here, on the NANOG list, allows people to make up their own minds and to ignore the relevant route announcements and/or cease peering if they are persuaded that 216.179.128.0/17 is likely a source of "undesirable" packets. 3) An investigation by ARIN of 216.179.128.0/17 could take weeks or perhaps even months. In contrast, packets, including bad ones, travel from one end of the planet to another in milliseconds. ARIN and its careful review processes are a sure and steady and reliable check on fradulent behavior over the longer term. But they will not do much to addres the bad packets that may be flowing out of 216.179.128.0/17 this week, or even next. 4) Filing a "fraud request" with ARIN is a serious step and one that could quite conceivably end up with the party filing such a formal report being on the business end of lawsuit, just for having filed such a report. Does ARIN indemnify the parties who file such reports against such claims, as ARIN is currently asking ARIN-region networks to do for ARIN if they want to avail themselves of the added security of RPKI? Regards, rfg
4) Filing a "fraud request" with ARIN is a serious step and one that could quite conceivably end up with the party filing such a formal report being on the business end of lawsuit, just for having filed such a report.
What makes you think that the sort of persons who would hijack a /17 sized piece of space, for spam generation purposes, would sue you over some formal submission you might make to ARIN, but would not already have sued you over your already exhaustively detailed posts to the public NANOG list? On Tue, Aug 13, 2019 at 12:18 PM Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
In message <D9973D64-91AB-4380-B5E8-DEE173726CC0@arin.net>, John Curran <jcurran@arin.net> wrote:
On 9 Aug 2019, at 4:09 PM, Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
... Unfortunately, we cannot read too much into this change that was made to the block's public-facing WHOIS record. Neither the new WHOIS info nor even the old WHOIS info can be used to reliably infer who or what is the legitimate registrant of the block at any point in time. This is because ARIN, like all of the other Regional Internet Registries, allows registrants to put essentially any bovine excrement they desire into their public-facing WHOIS records.
That is not the case – ARIN confirms the legal status of organizations receiving number resources.
This is NOT the message that I got from our recent discussion of the giant Micfo fraud on the ARIN Public Policy Mailing List. When I raised questions about why various of the Micfo phoney baloney shell companies has block with WHOIS records saying they were located in states that they were obviously not located in, I believe that you said that once a black has been allocated, by ARIN, to some (properly vetted) entity, that after that point in time, the entity could -change- the relevant WHOIS record to say any bloody thing it wanted, and that such -changes- to ARIN WHOIS records are not vetted in any way.
If I got the Wrong Impression from your prior statements, then by all means, please do correct me. And then please do explain why several of the Micfo phony shell companies did in fact have WHOIS records for ARIN- issued IPv4 space that gave street addreses in states where none of these phony shell companies were actually registered to do business.
(And, it should be noted, the man behind the recent large scale "Micfo" fraud apparently availed himself of this exact opportunity far subterfuge, in spades.)
As previously noted on this list, such was only possible because of the use of falsely notarized documents.
I -do- understand that the fradulent documents that were originally presented to you/ARIN provided information indicating that the phoney Micfo shell companies -did- actually exist in -some- state (Delaware?), and that ARIN -did- verify, to the best of its ability, that those companies -did- exist, legally spekaing, in their originally declared home state(s). But that fact is just skirting the real issue here, which is the question of whether or not ARIN even looks at -changes_ that a registrant may make to the WHOIS records (e.g. for IPv4 blocks) -after- those blocks have been assigned.
It appears from where I am sitting that ARIN dos not do so. And thus, I stand by my comment that a registrant -can- in fact put any bloody nonsense they want into their WHOIS records, at least as long as they do it via -changes- and not in the original/initial WHOIS records.
Regardless, the available records suggest that there are only two likely possibilities in this case:
{trimmed} 1) 216.179.128.0/17 was transferred in violation of ARIN policy.
2) The current WHOIS for 216.179.128.0/17 is simply fradulent.
That is easy to address: submit a fraud request, and it will be reviewed and corrected if it was done fraudulently.
I would do that, but for the following four things:
1) ARIN is not the Internet Police and has no power to affect routing decisions of anybody.
2) Getting the info out here, on the NANOG list, allows people to make up their own minds and to ignore the relevant route announcements and/or cease peering if they are persuaded that 216.179.128.0/17 is likely a source of "undesirable" packets.
3) An investigation by ARIN of 216.179.128.0/17 could take weeks or perhaps even months. In contrast, packets, including bad ones, travel from one end of the planet to another in milliseconds. ARIN and its careful review processes are a sure and steady and reliable check on fradulent behavior over the longer term. But they will not do much to addres the bad packets that may be flowing out of 216.179.128.0/17 this week, or even next.
4) Filing a "fraud request" with ARIN is a serious step and one that could quite conceivably end up with the party filing such a formal report being on the business end of lawsuit, just for having filed such a report.
Does ARIN indemnify the parties who file such reports against such claims, as ARIN is currently asking ARIN-region networks to do for ARIN if they want to avail themselves of the added security of RPKI?
Regards, rfg
In message <CAB69EHiWkmEACduS2U1WaDQRfk03Xmvd9S0DGro9FcgxUyXKeQ@mail.gmail.com>, Eric Kuhnke <eric.kuhnke@gmail.com> wrote: rfg>> 4) Filing a "fraud request" with ARIN is a serious step and one that rfg> could quite conceivably end up with the party filing such a formal rfg> report being on the business end of lawsuit, just for having filed rfg> such a report. rfg>
What makes you think that the sort of persons who would hijack a /17 sized piece of space, for spam generation purposes, would sue you over some formal submission you might make to ARIN, but would not already have sued you over your already exhaustively detailed posts to the public NANOG list?
Let me see if I understand this. You don't have any argument with the other three reasons I gave for sending my alert to the NANOG list, but you -would- like to quible with reason #4. Have I understood you clearly? Assuming so, let me answer your question with a question (or two). Is my fear of the potential for lawsuits actually LESS reasonable than ARIN's use of the same vague and non-specific bogeyman to thwart and impede, on a global scale, the more widespread adoption of RPKI... adoption which would, if it ever became universal, put an end to most or all of these nefarious and malevolent IP block hanky panky games? The last time I looked, RPKI adoption was sitting at around a grand total of 15% worldwide. Ah yes, here it is... https://rpki-monitor.antd.nist.gov/ I've asked many people and many companies why adoption remains so low, and why their own companies aren't doing RPKI. I've gotten the usual assortment of utterly lame excuses, but the one that I have had the hardest time trying to counter is the one where a network engineer says to me "Well, ya know, we were GOING to do that, but then ARIN... unlike the other four regional authorities... demanded that we sign some silly thing indemnifying them in case of.... something. We're not even sure what ``something'' actually is in this case, other than some demented lawsuit from some deranged ``lone wolf'' individual, but since ARIN demanded that we sign it, the thing had to go to -our- lawyers, and they took one look at it and said, in effect, ``F that! We are NOT going to accept any new potential liability if we don't have to'', so that was the end of that." As I have often said, if we all only did things that had been pre-cleared as being ``utterly safe'' by our respective lawyers, then none of us would ever even get out of bed in the morning. Regadless of whether ARIN was in any way indemnified against such an event, the Micfo guy elected to name ARIN in a lawsuit. This is a matter of public record. It's ludicrous and laughable, obviously, but he apparently sued ARIN when they woudn't just roll over and allow him to continue to play his ridiculous little fraud games. Like I say, in this country, at least (USA), you run the risk of getting sued if you even so much as get out a bed in the morning. BUT SO BLOODY WHAT? Neither we as individuals nor ARIN as an organization should cower in fear in our caves because of a bogeyman that may never come to pass, or that may be totally inconsequential even if it does, as in the case of Mr. Micfo's joke of a lawsuit. So I put it to everyone here... Are ARIN policies and its over-hyped fear of the vague bogeyman of lawsuits materially impeding the adoption of RPKI, and if so, what should be done about this? In the meantime, I decline to accept criticism of -my- perhaps misplaced fears of lawsuits. Mine have essentially no real world consequences. ARIN's, on the other hand, appear to be keeping some finite non-zero fraction of 85% of the world's route announcements unchecked, at least for any meaningful sense of the word "checked". Regards, rfg
On 13 Aug 2019, at 9:28 PM, Ronald F. Guilmette <rfg@tristatelogic.com<mailto:rfg@tristatelogic.com>> wrote: ... The last time I looked, RPKI adoption was sitting at around a grand total of 15% worldwide. Ah yes, here it is... https://rpki-monitor.antd.nist.gov/ I've asked many people and many companies why adoption remains so low, and why their own companies aren't doing RPKI. I've gotten the usual assortment of utterly lame excuses, but the one that I have had the hardest time trying to counter is the one where a network engineer says to me "Well, ya know, we were GOING to do that, but then ARIN... unlike the other four regional authorities... demanded that we sign some silly thing indemnifying them in case of.... something. Interestingly enough, those same indemnification clauses are in the registration services agreement that they already signed but apparently they were not an issue at all when requesting IP address space or receiving a transfer. You might want want to ask them why they are now a problem when they weren’t before (Also worth noting that many of these ISP's own contracts with their customers have rather similar indemnification clauses.) Even so, we at ARIN are in the midst of a Board-directed review of the RPKI legal framework to see if any improvements can be made <https://www.arin.net/vault/participate/meetings/reports/ARIN_43/PDF/PPM/curran_rpki.pdf> – I will provide further updates once it is completed. Thanks! /John John Curran President and CEO American Registry for Internet Numbers
On Tue, Aug 13, 2019 at 7:42 PM John Curran <jcurran@arin.net> wrote:
On 13 Aug 2019, at 9:28 PM, Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
The last time I looked, RPKI adoption was sitting at around a grand total of 15% worldwide. Ah yes, here it is...
https://rpki-monitor.antd.nist.gov/
I've asked many people and many companies why adoption remains so low, and why their own companies aren't doing RPKI. I've gotten the usual assortment of utterly lame excuses, but the one that I have had the hardest time trying to counter is the one where a network engineer says to me "Well, ya know, we were GOING to do that, but then ARIN... unlike the other four regional authorities... demanded that we sign some silly thing indemnifying them in case of.... something.
Interestingly enough, those same indemnification clauses are in the registration services agreement that they already signed but apparently they were not an issue at all when requesting IP address space or receiving a transfer.
I signed no legal agreement either to register my legacy addresses or to do a whois lookup to check someone else's addresses. Just sayin'. -- William Herrin bill@herrin.us https://bill.herrin.us/
On 13 Aug 2019, at 11:03 PM, William Herrin <bill@herrin.us<mailto:bill@herrin.us>> wrote: On Tue, Aug 13, 2019 at 7:42 PM John Curran <jcurran@arin.net<mailto:jcurran@arin.net>> wrote: On 13 Aug 2019, at 9:28 PM, Ronald F. Guilmette <rfg@tristatelogic.com<mailto:rfg@tristatelogic.com>> wrote: The last time I looked, RPKI adoption was sitting at around a grand total of 15% worldwide. Ah yes, here it is... https://rpki-monitor.antd.nist.gov/ I've asked many people and many companies why adoption remains so low, and why their own companies aren't doing RPKI. I've gotten the usual assortment of utterly lame excuses, but the one that I have had the hardest time trying to counter is the one where a network engineer says to me "Well, ya know, we were GOING to do that, but then ARIN... unlike the other four regional authorities... demanded that we sign some silly thing indemnifying them in case of.... something. Interestingly enough, those same indemnification clauses are in the registration services agreement that they already signed but apparently they were not an issue at all when requesting IP address space or receiving a transfer. I signed no legal agreement either to register my legacy addresses or to do a whois lookup to check someone else's addresses. Just sayin’. Bill - When you did that Whois look up at the ARIN website, you did agree to terms of use for the Whois service which contains indemnification provisions and are legally enforceable. <https://www.arin.net/resources/registry/whois/tou/> If you instead used a command line interface (e.g. "whois -h whois.arin.net<http://whois.arin.net> …”), then you received output from ARIN’s Whois server along with notice of the applicable terms of service… I would observe that continued use at that point has been held to indicate agreement on your part [ref: Register.com<http://Register.com>, Inc. v. Verio, Inc., 356 F.3d 393 (2d Cir. 2004)] Thanks, /John John Curran President and CEO American Registry for Internet Numbers
On 14/08/2019 06:24, John Curran wrote:
When you did that Whois look up at the ARIN website, you did agree to terms of use for the Whois service which contains indemnification provisions and are legally enforceable. <https://www.arin.net/resources/registry/whois/tou/>
If you instead used a command line interface (e.g. "whois -h whois.arin.net <http://whois.arin.net> …”), then you received output from ARIN’s Whois server along with notice of the applicable terms of service… I would observe that continued use at that point has been held to indicate agreement on your part [ref: Register.com <http://Register.com>, Inc. v. Verio, Inc., 356 F.3d 393 (2d Cir. 2004)]
Thanks, /John
John Curran President and CEO American Registry for Internet Numbers
Just like to add kudos to John for being open and responsive on this list and other lists to numerous issues and questions in regards to ARIN. Not many CEOs are willing or able to respond as you do. Thanks for your time and effort, -Hank
On Tue, Aug 13, 2019 at 9:51 PM Hank Nussbacher <hank@efes.iucc.ac.il> wrote:
Just like to add kudos to John for being open and responsive on this list and other lists to numerous issues and questions in regards to ARIN. Not many CEOs are willing or able to respond as you do.
Thanks for your time and effort,
I'll second that despite my criticism. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
On 14 Aug 2019, at 12:51 AM, Hank Nussbacher <hank@efes.iucc.ac.il> wrote:
… Just like to add kudos to John for being open and responsive on this list and other lists to numerous issues and questions in regards to ARIN. Not many CEOs are willing or able to respond as you do.
Hank - Thanks! – as I work for you (i.e. this collective community), I see it as a reasonable obligation to be reachable/answerable regarding how your registry is being run. /John John Curran President and CEO American Registry for Internet Numbers p.s. As a reminder, those interested in more prominent/direct role in oversight of ARIN should consider running for the Board of Trustees… <https://www.arin.net/announcements/20190723/>
On 13 Aug 2019, at 11:03 PM, William Herrin <bill@herrin.us> wrote: I signed no legal agreement either to register my legacy addresses or to do a whois lookup to check someone else's addresses. Just sayin’.
If you instead used a command line interface (e.g. "whois -h whois.arin.net …”), then you received output from ARIN’s Whois server along with notice of
On Tue, Aug 13, 2019 at 8:25 PM John Curran <jcurran@arin.net> wrote: the applicable terms of service… Hi John, As I no longer live within or act from within one of the 2 states to have passed UCITA, you'll find that notice difficult to enforce.
I would observe that continued use at that point has been held to indicate agreement on your part [ref: Register.com, Inc. v. Verio, Inc., 356 F.3d 393 (2d Cir. 2004)]
In which Verio admitted to the court that they knew they were abusing Register's computers but figured Register's contract with ICANN gave them the right. The court would have reached the same decision regardless of Register's notice: You're abusing computers that aren't yours. Stop it. Specht v. Netscape Communications Corp, on the other hand, found that, "plaintiffs neither received reasonable notice of the existence of the license terms nor manifested unambiguous assent" to the contract Netscape offered for the use of their software at download-time, including assent to settle disputes through arbitration. I'll take any bet you care to offer that the latter precedent applies to casual consumer use of ARIN's whois. I won't take any such bet when it comes to the legal safety of redistributing ARIN's RPKI Trust Anchor Locator in my software. And neither, apparently, do many of the folks who would have to redistribute that TAL for ARIN's RPKI to be useful, as was discussed here last September: https://mailman.nanog.org/pipermail/nanog/2018-September/097161.html Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
On 14 Aug 2019, at 1:01 AM, William Herrin <bill@herrin.us> wrote:
...
I would observe that continued use at that point has been held to indicate agreement on your part [ref: Register.com, Inc. v. Verio, Inc., 356 F.3d 393 (2d Cir. 2004)]
In which Verio admitted to the court that they knew they were abusing Register's computers but figured Register's contract with ICANN gave them the right. The court would have reached the same decision regardless of Register's notice: You're abusing computers that aren't yours. Stop it.
BIll - The particular finding from Register v. Verio that is relevant was that a user made aware of applicable terms with each query (even at the end) is sufficient for contractual binding after continued use.
Specht v. Netscape Communications Corp, on the other hand, found that, "plaintiffs neither received reasonable notice of the existence of the license terms nor manifested unambiguous assent" to the contract Netscape offered for the use of their software at download-time, including assent to settle disputes through arbitration.
Register v. Verio was after Specht v Netscape, and distinguished the situation where the user received terms at the end of each response from those cases where a user couldn’t reasonably determine that there were any applicable terms and conditions.
I'll take any bet you care to offer that the latter precedent applies to casual consumer use of ARIN's whois.
That bet is available to you at any time by violating the terms the ARIN’s Whois service, so the question to ask yourself is: "do you feel lucky?” Thanks, /John John Curran President and CEO American Registry for Internet Numbers
In message <06570278-E1AD-4BB0-A9FC-11A77BED76E1@arin.net>, John Curran <jcurran@arin.net> wrote:
Even so, we at ARIN are in the midst of a Board-directed review of the RPKI legal framework to see if any improvements can be made <https://www.arin.net/ vault/participate/meetings/reports/ARIN_43/PDF/PPM/curran_rpki.pdf> – I will provide further updates once it is completed.
This is an excellent presentation John, and I'm real glad to see that you have done such a nice job on it and touched on all of the important points. In particular, I'm glad that you clarified that if everyone is just doing what they ought to be doing, i.e. following best practices, then even if RPKI central and all of its sister satellites should all be simultaneously hit by metorites, then in theory at least, nobody should be any worse off than they already are today. And yes, I can't argue and won't argue that some folks aren't going to be bozos and screw up their RPKI deployment, and then some of them -may- possibly want to blame ARIN for -their- screw ups, but I continue to have trouble envisioning how this would ever traslate into a lawsuit that wouldn't simply be laughed out of court in about five seconds if handled properly. Some arguably proximate historical analogs might be relevant here. In the past, there have occasionally been problems when one or more of the root name servers have been DDoSd or have otherwise had issues. I don't recall anybody lining up to sue ICANN in those instances. Spamhaus and other public anti-spam services publish their stuff to all comers, without demanding indemnification. Yes, they have been sued from time to time, but none of that has ever resulted in any meaningful damages, and if the company itself had just been more consistant in obtaining sound legal advice, none of those events would even have been all that bothersome. So, what makes ARIN so special that it can't do what these others are doing and just simply publish some information? ARIN is in the State of Virginia the last time I checked, and I do believe that the First Amendment still applies in the State of Virginia, and indeed in all 50 states. I mean it isn't as if ARIN is going to go around yelling "Fire!" in a crowded theater for God's sake! So, you just slap a label on the whole bloody RPKI thing that says "Use at your own risk" and that ought to do it, I think. I understand that Steve Ryan may not see it that way, but it's his job not to see it that way. In practice, there is no need for -both- belt -and- suspenders. Regards, rfg P.S. Proactive failure testing (slide #15) is an excellent idea. You could and probably should fail the whole thing deliberately for 24 hours once a year, just as a way of shaking the trees to see what idiots fall out. It would be like DNS Flag Day, on steroids.
On 14 Aug 2019, at 1:21 AM, Ronald F. Guilmette <rfg@tristatelogic.com<mailto:rfg@tristatelogic.com>> wrote: In message <06570278-E1AD-4BB0-A9FC-11A77BED76E1@arin.net<mailto:06570278-E1AD-4BB0-A9FC-11A77BED76E1@arin.net>>, John Curran <jcurran@arin.net<mailto:jcurran@arin.net>> wrote: Even so, we at ARIN are in the midst of a Board-directed review of the RPKI legal framework to see if any improvements can be made <https://www.arin.net/ vault/participate/meetings/reports/ARIN_43/PDF/PPM/curran_rpki.pdf> – I will provide further updates once it is completed. This is an excellent presentation John, and I'm real glad to see that you have done such a nice job on it and touched on all of the important points. In particular, I'm glad that you clarified that if everyone is just doing what they ought to be doing, i.e. following best practices, then even if RPKI central and all of its sister satellites should all be simultaneously hit by metorites, then in theory at least, nobody should be any worse off than they already are today. And yes, I can't argue and won't argue that some folks aren't going to be bozos and screw up their RPKI deployment, and then some of them -may- possibly want to blame ARIN for -their- screw ups, but I continue to have trouble envisioning how this would ever traslate into a lawsuit that wouldn't simply be laughed out of court in about five seconds if handled properly. Alas, it’s not those who fail to properly configure RPKI that are likely to be litigating, but rather their impacted customers and those customers' business partners who all were unable to communicate due to no fault of their own. Such a matter will not be thrown out of court, but will be the start of a long and very expensive process involving claims, discovery, experts, etc. (a recent legal matter that was promptly resolved in ARIN’s favor pre-litigation still resulted in more than 1/3 million USD in costs...) Absent a specific reason for dismissal, it is only in actual trial that the preponderance of evidence gets considered – and note that in such a dispute, we’d end up with a jury of regular folks hearing fairly technical arguments about certificate validation, covering ROA’s, caching, etc. In other words, even if handled perfectly, your five second estimate is likely off by a year or more (and hence the reason for indemnification - it provides a clear basis for ARIN’s exit from the matter, as it makes plain that the liability resulting from use of the RPKI repository lies with the ISP.) Thanks, /John John Curran President and CEO American Registry for Internet Numbers
In message <F5375602-22D5-4983-8D8D-27252732E874@arin.net>, John Curran <jcurran@arin.net> wrote:
Alas, it’s not those who fail to properly configure RPKI that are likely to be litigating, but rather their impacted customers and those customers' business partners who all were unable to communicate due to no fault of their own.
Such a matter will not be thrown out of court, but will be the start of a long and very expensive process involving claims, discovery, experts, etc...
Perhaps. There are certainly some big players (AWS) that if routing were interrupted for even, say, 12 hours, a lot of folks would get really mad about. Correct me if I'm wrong, but one of your presentation slides seemed to suggest that a separate arms-length legal entity could be established to do the RPKI stuff, thus offloading most or all of the potential liability onto and into this separate entity, which could conveniently have minimal assets of the kind that might inspire members of the plaintiff's bar who are looking for deep pockets. Is that an actual possibility, or did you just throw that in there for the sake of completness? Personally, I don't much care how the problem gets solved, as long as it gets solved. The fundamental BGP problem has been known and discussed now for 20+ years and it is only getting more dire and ominous, day by day. Regards, rfg
On Tue, Aug 13, 2019 at 5:44 PM John Curran <jcurran@arin.net> wrote:
On 13 Aug 2019, at 9:28 PM, Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
... The last time I looked, RPKI adoption was sitting at around a grand total of 15% worldwide. Ah yes, here it is...
https://rpki-monitor.antd.nist.gov/
I've asked many people and many companies why adoption remains so low, and why their own companies aren't doing RPKI. I've gotten the usual assortment of utterly lame excuses, but the one that I have had the hardest time trying to counter is the one where a network engineer says to me "Well, ya know, we were GOING to do that, but then ARIN... unlike the other four regional authorities... demanded that we sign some silly thing indemnifying them in case of.... something.
Interestingly enough, those same indemnification clauses are in the registration services agreement that they already signed but apparently they were not an issue at all when requesting IP address space or receiving a transfer. You might want want to ask them why they are now a problem when they weren’t before (Also worth noting that many of these ISP's own contracts with their customers have rather similar indemnification clauses.)
Hi John, There are things companies will sign when their backs are up against the wall that they will balk at signing when it is for an optional geek-ish extra. IP addresses are the lifeblood of the tech industry. If you don't have an IP address, you don't exist on the Internet. (Apologies to those of us who still have modems configured to call and retrieve mail addressed with UUCP bang paths). So, companies will grudgingly and with much hand-wringing sign the RSA necessary to get IP space. Without, they die. Rather like oxygen; if we had to sign a license agreement in order to receive air to breathe, you'd find most people would sign pretty horrific terms of service agreements. Slip those same terms in front of someone as a requirement for them to buy beer, and you'll likely discover a whole lot of people are just fine drinking something else instead. So too with the RSA terms versus the RPKI terms. As companies, we can't survive without IP addresses. We'll sign just about anything to stay alive. RPKI is a geek toy. It's not at all required for a business to stay alive on the Internet, so companies feel much safer in saying "no way will we sign that!". Now, at the risk of bringing down the ire of the community on my head...ARIN could consider tying the elements together, at least for ARIN members. Add the RPKI terms into the RSA document. You need IP number resources, congratulations, once you sign the RSA, you're covered for RPKI purposes as well. That doesn't solve the issue for out-of-region folks who don't have an RSA with ARIN; but that's no worse than you are today; and by bundling the RPKI terms in with the rest of the RSA, you at least get everyone in the ARIN region that wants^Wneeds to maintain their IP number resources in order to stay in business on the Internet covered in terms of being able to use the RPKI data. If you've got them by the short and curlies already, might as well bundle everything in while they've got the pen in their hand. ^_^; Even so, we at ARIN are in the midst of a Board-directed review of the RPKI
legal framework to see if any improvements can be made < https://www.arin.net/vault/participate/meetings/reports/ARIN_43/PDF/PPM/curran_rpki.pdf> – I will provide further updates once it is completed.
Best of luck! I know we'll all be watching carefully to see how it goes. :) Matt
Thanks! /John
John Curran President and CEO American Registry for Internet Numbers
On 14 Aug 2019, at 2:26 AM, Matthew Petach <mpetach@netflight.com> wrote:
... Now, at the risk of bringing down the ire of the community on my head...ARIN could consider tying the elements together, at least for ARIN members. Add the RPKI terms into the RSA document. You need IP number resources, congratulations, once you sign the RSA, you're covered for RPKI purposes as well.
Matthew - Yes indeed - this is one of several potential improvements that we’re also investigating. Thanks! /John John Curran President and CEO American Registry for Internet Numbers
Dear all, On Wed, Aug 14, 2019 at 10:36:44AM +0000, John Curran wrote:
On 14 Aug 2019, at 2:26 AM, Matthew Petach <mpetach@netflight.com> wrote:
... Now, at the risk of bringing down the ire of the community on my head...ARIN could consider tying the elements together, at least for ARIN members. Add the RPKI terms into the RSA document. You need IP number resources, congratulations, once you sign the RSA, you're covered for RPKI purposes as well.
Matthew -
Yes indeed - this is one of several potential improvements that we’re also investigating.
I've attempted to produce a humorous world map chart to help clarify there is a degree of asymmetry our community may need to consider: http://instituut.net/~job/screenshots/e079d90a-3047-4034-8e7c-9caf6e387f1a.p... The ARIN members (mostly located in the red area) would like all not-ARIN-members (located in the blue area, the rest of the world) to use and honor their ROAs published through ARIN's RPKI service. If not for the purpose of facilitating BGP Origin Validation on as many as possible of Internet's routers to protect one's IP resources, why else would anyone publish RPKI ROAs through their RIR? In other words: ARIN members want something (something very reasonable!) from "the rest of the world", but in order to accomplish that 'something', unfortunately "the rest" needs to agree to the ARIN RPA. This has proven to be somewhat of an adoption barrier. It would be fantastic when "the rest" are not required to do any such thing and the ARIN RPKI TAL can be distributed without restrictions or limitations. I would love to see any solution that removes all potential friction for "the rest of the world", even if that shifts some additional burden to ARIN members themselves; because it's ARIN members that want something from the world, less so the other way around. On Wed, Aug 14, 2019 at 4:42 AM John Curran <jcurran@arin.net> wrote:
Interestingly enough, those same indemnification clauses are in the registration services agreement that they already signed but apparently they were not an issue at all when requesting IP address space or receiving a transfer.
Your observation (if correct) indeed is very interesting, and perhaps demonstrates that RPKI business is something between ARIN and ARIN's members, and less so between ARIN and all other potential relaying parties on this planet. Or phrased differently: perhaps only ARIN members should be the ones incurring the cost and burden of reviewing and accepting ARIN's agreements. I'd like to express my appreciation to ARIN's staff & ARIN's Board of Trustees for dedicating their time and resources to research how to improve in this context. Kind regards, Job ps. Ofcourse this map is an oversimplification of the situation, apologies for any inaccuracies.
On Wed, 14 Aug 2019 02:42:09 -0000, John Curran said:
You might want want to ask them why they are now a problem when they weren’t before (Also worth noting that many of these ISP's own contracts with their customers have rather similar indemnification clauses.)
Actually, it's probably ARIN that should be doing the asking, and seeing if they can change the wording and/or rephrase the issue to allay concerns. It sounds to me like ARIN's *intent* was "if you get sued by your customers because you screw the pooch on deployment, it's your screw-up to clean up and not our problem". Or at least I *hope* that was the intent (see next paragraph) But I suspect a lot of companies are reading it as: "If a spammer sues you for using a block list that prevents them from spamming your customers, you can't end up owing money to the block list maintainers. But if you rely on the ARIN TAL, and get sued by an address hijacker, you could end up owing money to ARIN". (Having said that, John, it takes a special sort of CEO to stand out and be seen in situations like this, and the world could probably use more CEO's like that...)
On 14 Aug 2019, at 11:15 AM, Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote:
On Wed, 14 Aug 2019 02:42:09 -0000, John Curran said:
You might want want to ask them why they are now a problem when they weren’t before (Also worth noting that many of these ISP's own contracts with their customers have rather similar indemnification clauses.)
Actually, it's probably ARIN that should be doing the asking, and seeing if they can change the wording and/or rephrase the issue to allay concerns.
It sounds to me like ARIN's *intent* was "if you get sued by your customers because you screw the pooch on deployment, it's your screw-up to clean up and not our problem". Or at least I *hope* that was the intent (see next paragraph)
That is indeed the intent - please deploy routing validation using best practices, so that you & your customers don’t suffer any adverse impact when ARIN's repository is not available.
But I suspect a lot of companies are reading it as: "If a spammer sues you for using a block list that prevents them from spamming your customers, you can't end up owing money to the block list maintainers. But if you rely on the ARIN TAL, and get sued by an address hijacker, you could end up owing money to ARIN”.
It’s is not “you owe money to ARIN’, but it could be “you need to defend both yourself and ARIN from your customers’ litigation should you get it wrong."
(Having said that, John, it takes a special sort of CEO to stand out and be seen in situations like this, and the world could probably use more CEO's like that…)
<chuckle> fairly easy to do if one has a thick skin… ;-) Thanks! /John John Curran President and CEO American Registry for Internet Numbers
On Wed, Aug 14, 2019 at 1:09 PM John Curran <jcurran@arin.net> wrote:
On 14 Aug 2019, at 11:15 AM, Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote:
On Wed, 14 Aug 2019 02:42:09 -0000, John Curran said:
You might want want to ask them why they are now a problem when they
before (Also worth noting that many of these ISP's own contracts with
weren’t their
customers have rather similar indemnification clauses.)
Actually, it's probably ARIN that should be doing the asking, and seeing if they can change the wording and/or rephrase the issue to allay concerns.
It sounds to me like ARIN's *intent* was "if you get sued by your customers because you screw the pooch on deployment, it's your screw-up to clean up and not our problem". Or at least I *hope* that was the intent (see next paragraph)
That is indeed the intent - please deploy routing validation using best practices, so that you & your customers don’t suffer any adverse impact when ARIN's repository is not available.
Or, move all your number resources to a subsidiary in the AP region, pay membership fees to APNIC instead of ARIN, and use their trust anchor instead of ARIN's. BTW, since all 5 RIRs have certificates signing the whole IP address space, it really makes no difference. Rubens
On Wed, 14 Aug 2019 16:07:49 -0000, John Curran said:
But I suspect a lot of companies are reading it as: "If a spammer sues you for using a block list that prevents them from spamming your customers, you can't end up owing money to the block list maintainers. But if you rely on the ARIN TAL, and get sued by an address hijacker, you could end up owing money to ARIN".
It's is not "you owe money to ARIN", but it could be "you need to defend both yourself and ARIN from your customers litigation should you get it wrong."
Is there any workable way to remove or diminish the perception of liability in the case of using it *correctly*? I admit that (a) I'm not a lawyer and (b) when I actually tried to read it I couldn't actually tell if it was "you promise to defend us if you screw it up and customer traffic gets accidentally dropped on the floor" or "you promise to defend us if you use it correctly and miscreant traffic is intentionally dropped on the floor"... There's obviously a disconnect where people aren't worried about indemnifying Spamhaus for using their block list, but are worried about indemnifying ARIN for using the TAL.
There's obviously a disconnect where people aren't worried about indemnifying Spamhaus for using their block list, but are worried about indemnifying ARIN for using the TAL.
That would be because there is a rather substantial difference between publishing an IP address for which you have spam in hand, and are saying (and only saying) "I received spam from this IP address" (not to mention something which people use to only affect inbound email), and hosting something on which others rely for making their acceptance decision of all legitimate Internet traffic, as well as for the ability to not move malicious (or even accidentally misconfigured) Internet traffic. Anne Anne P. Mitchell, Attorney at Law Dean of Cybersecurity & Cyberlaw, Lincoln Law School of San Jose CEO/President, Institute for Social Internet Public Policy SuretyMail Email Reputation Certification Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant Board of Directors, Denver Internet Exchange Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Former Counsel: Mail Abuse Prevention System (MAPS) Member: California Bar Association
Hi John,
John Curran wrote : Even so, we at ARIN are in the midst of a Board-directed review of the RPKI legal framework to see if any improvements can be made <https://www.arin.net/vault/participate/meetings/reports/ARIN_43/PDF/PPM/curran_rpki.pdf> – I will provide further updates once it is completed.
Thanks, we appreciate the effort. That being said, something has to be done. I feel that the RPKI validation by ARIN is somehow useless. Why : because few download the TAL (at least in part because of the indemnisation clause). Therefore, many networks that do RPKI validation do validate prefixes from the other 4 RIRs but not mine. In simple words : why bother validating, if all of most of the networks that could block invalid prefixes don't, because the TAL agreement is not palatable. I understand that ARIN has to deal with a legal system that makes things difficult, but OTOH I would like ARIN's RPKI validation to provide the same protection than the other RIRs, which it currently does not. I created my ROAs, but I am not protected as well as an Org belonging to another RIR. Michel TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!...
On 13/08/2019 22:17, Ronald F. Guilmette wrote: Just as an observer to your long resource theft postings: - Do you attempt to contact directly the organization or person who have had their resource taken over? - Do they care or are they apathetic? - If the resource owner is no where to be found, why should we as a community care? Report it on some webpage and call it "Internet Resources stolen", document every incident as you do via email, send a copy to the appropriate RIR and upstream ISP allowing the hijack in question to show that you did the appropriate effort and we can then move on. Regards, Hank
In message <4fcb73bf-224f-e011-f310-522193c86667@efes.iucc.ac.il>, Hank Nussbacher <hank@efes.iucc.ac.il> wrote:
Just as an observer to your long resource theft postings: - Do you attempt to contact directly the organization or person who have had their resource taken over?
To the extent that I can spare the time, and to the extent that I am able to do so, (which is often limited by time zone differences) yes, I do.
- Do they care or are they apathetic?
Before answering let me clarify first the two different classes of problems that I've most often been looking at. Everybody including myself has in the past used the term "hijack" but I'm going to try to stop doing that, in future, and instead use the more precise terms "squatting" and "theft", where "theft" involves a case where the relevant WHOIS records have been materially "fiddled" by the usurper. In both cases, the usurpers generally aim, first and foremost, for the low hanging fruit, which is to say legacy blocks that were abandoned years and years ago, sometimes even decades ago, back when IP addresses had zero monitizable value. When contacted, victims in these cases are typically at first utterly perplexed, and when I explain to them that I am trying to give them back stuff that they already own, and which in some cases is worth considerable money on the open market, they *do* look a gift horse in the mouth, and they assume, quite reasonably I think, given the current way of the world, that *I* am trying to run some kind of elaboarate scam on them. It takes a lot of talking on my part to convince them that no. I'm actually just a good samaritan, and that no, I am -not- going to be asking them to first send any sort of "release fee" via WesterUnion or Bitcoin or WebMoney before they can have their own blocks back. Even after they have been convinced that this ain't a scam and that they do own the stuff I say they own, most are often entirely lackadaisical about getting off their butts and then working with the relevant RIRs to get their own stuff back. Even when I try to get them fired up by telling them that "cybercriminals" have stolen their blocks, and the fact that evil that is being done under their names may negatively affect THEIR public reputations, it's still like watching paint dry, for me anyway. Clearly, nobody but me has any sense of urgency about these things at all.
- If the resource owner is no where to be found, why should we as a community care?
I'm so glad you asked. Before answering I should first note that it is actually quite rare when a sufficient amount of research on my part fails to turn up a relevant "successor or assign" which would, by rights, be the modern day entity with a legitimate claim on the asset. So the "nowhere to be found" case is by far the exception, rather than the rule. Regardless, in -either- the case where no heir can be found -or- in the case where the rightful heir is either just too dumb or just too lazy to take the minimal steps necessary to reclaim the property (and/or before this has ocurred) the community should care because the kind of people who either steal or squat on IPv4 blocks are, almost without exception, not the kind of people who anybody sane wants to be accepting packets from, let alone peering with. There is, in my opinion and experience, a high degree of correlation between skulduggery with respect to -obtaining- (illicitly) IPv4 address blocks and using those addresses in a manner which is not at all conducive to the general welfare of the Internet or its users.
Report it on some webpage and call it "Internet Resources stolen", document every incident as you do via email, send a copy to the appropriate RIR and upstream ISP allowing the hijack in question to show that you did the appropriate effort and we can then move on.
I can and will stop posting here, and go off an blog about this stuff instead, if the consensus is that I'm utterly off-topic or utterly uninteresting and useless. But a few folks have told me they find this stuff interesting, and it has operational significance, I think. So for now, at least, I'd like to continue to share here. As regards to reporting to RIRs or upstreams, what makes you think that either of those would care one wit? The RIRs are not the Internet Police, or so I am told. They don't configure routers. Upstreams are, in my experience utterly intransigent and unresponsive, especially in the absence of public exposure of the self-evident problem(s).... like the time I tried to get Telecom Italia to get off their asses and do something... anything... about their criminal mass squatting customer. It wasn't until much later on, after WhiteOps and Google had exposed the massive click fraud operation that was behind all that that Telecom Italia saw fit to lift even a single finger to actaully DO anything at all. And the last time I looked, Telecom Italia was *still* peering with the exact same crooked ASN, even though most or all of the people who were identified, by LE, and being behind it are nowaadays facing numerous federal criminal charges here in the U.S. Please remember also that there are two separate classes of problems involved here, i.e. mere "sqyuatting" and separately, "theft", where some clever crook has managed to get in and actually fiddle with one or more RIR-maintained WHOIS records. I very explicitly -do not- want to just report this latter class of incidents exclusively and only to the RIRs themselves. Some of these cases raise quite serious questions about the operation of and oversight of various RIRs, and I feel very strongly that those questions deserve to be kicked around in public, and not just between myself and the relevant RIRs, some of whom, at least, may have more than a little incentive to just sweep these things entirely under the carpet. I apologize for being vague and non-specific. For now, I need to be. Later I will be providing further clarity to all I have said above. Regards, rfg
On 15/08/2019 06:16, Ronald F. Guilmette wrote:
- If the resource owner is no where to be found, why should we as a community care? I'm so glad you asked.
Regardless, in -either- the case where no heir can be found -or- in the case where the rightful heir is either just too dumb or just too lazy to take the minimal steps necessary to reclaim the property (and/or before this has ocurred) the community should care because the kind of people who either steal or squat on IPv4 blocks are, almost without exception, not the kind of people who anybody sane wants to be accepting packets from, let alone peering with. There is, in my opinion and experience, a high degree of correlation between skulduggery with respect to -obtaining- (illicitly) IPv4 address blocks and using those addresses in a manner which is not at all conducive to the general welfare of the Internet or its users.
So if the rightful is apathetic, then won't these new "malicious blocks" just end up in numerous blacklists and all the illegal activity being performed from those usurped blocks will just be blocked in the end? Since the RIRs won't do much(as much as we have tried) why not just leave it be (as much as it may hurt to do that) and let the bad blocks just become part of the blacklist sludgepool?
Report it on some webpage and call it "Internet Resources stolen", document every incident as you do via email, send a copy to the appropriate RIR and upstream ISP allowing the hijack in question to show that you did the appropriate effort and we can then move on. I can and will stop posting here, and go off an blog about this stuff instead, if the consensus is that I'm utterly off-topic or utterly uninteresting and useless. But a few folks have told me they find this stuff interesting, and it has operational significance, I think. So for now, at least, I'd like to continue to share here.
Suggestion: post here a link to your new blog for every incident you find. State here something like "/22 stolen from xxxx registered in country aaa by yyy located in country bbb". Those that are interested will click on the link and I suggest you allow comments on every blog post so that people can respond and comment. Regards, Hank
On 14 Aug 2019, at 11:16 PM, Ronald F. Guilmette <rfg@tristatelogic.com<mailto:rfg@tristatelogic.com>> wrote: Report it on some webpage and call it "Internet Resources stolen", document every incident as you do via email, send a copy to the appropriate RIR and upstream ISP allowing the hijack in question to show that you did the appropriate effort and we can then move on. I can and will stop posting here, and go off an blog about this stuff instead, if the consensus is that I'm utterly off-topic or utterly uninteresting and useless. But a few folks have told me they find this stuff interesting, and it has operational significance, I think. So for now, at least, I'd like to continue to share here. As regards to reporting to RIRs or upstreams, what makes you think that either of those would care one wit? The RIRs are not the Internet Police, or so I am told. Good morning Ron – The RIRs are not the Internet Police, but we do care very much about the integrity of the Internet number registry system. Please report to ARIN any instances of number resource records in the ARIN registry whose organization you believe to be incorrect – while such records are updated only based on appropriate documentation, that doesn’t preclude the use of fraudulent documentation that goes undetected. Thanks! /John John Curran President and CEO American Registry for Internet Numbers
(I hate to step into the pond, but...) On Thu, Aug 15, 2019 at 8:02 AM John Curran <jcurran@arin.net> wrote:
On 14 Aug 2019, at 11:16 PM, Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
Report it on some webpage and call it "Internet Resources stolen", document every incident as you do via email, send a copy to the appropriate RIR and upstream ISP allowing the hijack in question to show that you did the appropriate effort and we can then move on.
I can and will stop posting here, and go off an blog about this stuff instead, if the consensus is that I'm utterly off-topic or utterly uninteresting and useless. But a few folks have told me they find this stuff interesting, and it has operational significance, I think. So for now, at least, I'd like to continue to share here.
As regards to reporting to RIRs or upstreams, what makes you think that either of those would care one wit? The RIRs are not the Internet Police, or so I am told.
Good morning Ron –
The RIRs are not the Internet Police, but we do care very much about the integrity of the Internet number registry system.
Please report to ARIN any instances of number resource records in the ARIN registry whose organization you believe to be incorrect – while such records are updated only based on appropriate documentation, that doesn’t preclude the use of fraudulent documentation that goes undetected.
There seem to be 2 different (at least) classes of thing Ron's noting here: 1) an aggregate (an ALLOCATION in RIR resource divying-up parlance) with (perhaps) bad data showing in WHOIS: 216.179.128.0/17 2) a subnet (an ASSIGNMENT in IR resource divying-up parlance) with bad data showing in WHOIS: 216.179.183.0/24 How data gets into the WHOIS system here is mechanically the same, but the control ARIN (or any RIR) can exert is drastically different. During the process of ALLOCATION from the RIR to an LIR (or end-site) there is some process which includes validating "who" and "where" and such, which John (and a few others) have outlined. During the ASSIGNMENT from LIR -> customer / end-site the LIR is solely (well.. mostly, yes the LIR can create and ORG and permit the Customer the ability to send SWIP updates....) in control of what data ends up in the WHOIS. ARIN (for example) has no real say in the records for ASSIGNMENTS. They could, I suppose, do something ... but that seems a lot like drinking from a firehose without any real ability on the part of ARIN (for instance) to validate anything in the inbound data :( -chris
Peace, On Thu, Aug 8, 2019 at 10:54 PM Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
Corporate identity theft is a simple ploy which may be used to illicitly obtain valuable IPv4 address space. Actual use of this fradulent ploy was first described publicly in April, 2008 (https://wapo.st/2YLEhlZ).
nostromo:tmp ximaera$ wc guilmette_combined.mbox 249 2122 13695 guilmette_combined.mbox nostromo:tmp ximaera$ I wish I had enough spare time to read this. May we have a tl;dr version of this? -- Töma
First he thought that a /17 got stolen (by creating a company with the same name as the original, now-defunct owner), but he then said he was wrong and actually it either 1) got transferred against ARIN policy or 2) was made to look like it was transferred by altering the whois data. On Fri, Aug 9, 2019, 4:47 PM Töma Gavrichenkov <ximaera@gmail.com> wrote:
Peace,
On Thu, Aug 8, 2019 at 10:54 PM Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
Corporate identity theft is a simple ploy which may be used to illicitly obtain valuable IPv4 address space. Actual use of this fradulent ploy was first described publicly in April, 2008 (https://wapo.st/2YLEhlZ).
nostromo:tmp ximaera$ wc guilmette_combined.mbox 249 2122 13695 guilmette_combined.mbox nostromo:tmp ximaera$
I wish I had enough spare time to read this.
May we have a tl;dr version of this?
-- Töma
In message <CA+FDdDTjDgHY=0+Ey-LDwsGtp3QvoktLrEDZ8HCrHXPUigha9g@mail.gmail.com> Ross Tajvar <ross@tajvar.io> wrote:
First he thought that a /17 got stolen (by creating a company with the same name as the original, now-defunct owner), but he then said he was wrong and actually it either 1) got transferred against ARIN policy or 2) was made to look like it was transferred by altering the whois data.
Yes. What he said. Although he left out the imporant detail that the whole thing appears to be just a smokescreen cover for a large spamming operation, which apparently targets primarily the Japanese market and which appears to have been ongoing since at least 2004: https://yomi.tokyo/agate/toki/bouhan/1103682730/1-/a Regards, rfg
participants (17)
-
Anne P. Mitchell, Esq. -
Christopher Morrow -
Eric Kuhnke -
Hank Nussbacher -
Job Snijders -
John Curran -
Kevin McCormick -
Marco Belmonte -
Matthew Petach -
Michel Py -
Rich Kulawiec -
Ronald F. Guilmette -
Ross Tajvar -
Rubens Kuhl -
Töma Gavrichenkov -
Valdis Klētnieks -
William Herrin