ARIN Fraud Reporting Form ... Don't waste your time

Mailman List Mirror (Read Only)
1

So ARIN put up on their web site this fancy schmancy web form that allows
a person to report fraud relating to ARIN number resources. Here's what
the introduction to that page says, exactly as it appears on ARIN's web
site:

     This reporting process is to be used to notify ARIN of suspected
     Internet number resource abuse including the submission of falsified
     utilization or organization information, unauthorized changes to data
     in ARIN's WHOIS, hijacking of number resources in ARIN's database, or
     fraudulent transfers.

Well, that's what it says anyway. And being naive, I actually believed that
the folks at ARIN might actually give a rat's ass about all these kinds of
fraud that they have enumerated above. Boy was I wrong!

I just received the response attached below to one of my earlier reports using
that form. And I gotta tell you, its an eye opener.

Apparently the fine folks at ARIN, clever bureaucrats that they are, have
subtly but substantially redefined the specific kinds of ``fraud'' they
care to hear about and/or investigate, so that contrary to the above, mere
hijacking of ASes or IP blocks isn't actually something that they want
to hear about, much less DO anything about.

Nope! Apparently, ARIN's fraud reporting form is only to be used for
reporting cases where somebody has fiddled one of ARIN's whois records
in a fradulent way. If somebody just waltzes in and starts announcing a
bunch of routes to a bunch of hijacked IP space from a hijacked ASN
(or two, or three) ARIN doesn't want to hear about it. In those rare
cases where the perp is considerate enough to ALSO fiddle the relevant
WHOIS records in some fradulent way, THEN (apparently) ARIN will get
involved, but only to the extent of re-jiggering the WHOIS record(s).
Once that's been done, they will happily leave the perp to announce
all of the fradulent routes and hijacked space he wants, in perpetuity.

Apparently, they consider the hijacking itself as being totally out of
their charter to even look at or investigate. ONLY if a WHOIS record
has been fiddled will they give a damn, and then the only one thing they
will give a damn about will be the WHOIS record... and the rest of the
net can go to hell, because hay! Not our problem man!

Now I _know_ full well that by posting this rant here, the usual assortment
of knuckle-walker throwbacks who still yearn for the wonderful rule-less
frontier every-man-for-himself-and-no-sherrifs fun filled days of the
old 20th Century Internet, will pipe up immediately and say `Good!
Goddammit we don't want no steekin' ARIN to be ``policing'' anything
at all. F**k that! Total anarchy is the best of all possible systems.'

You know what? I don't care. Let them come. Let them lumber around and
scream and pound their fists and try to tell me that because *I* didn't
get onto the Internet until 1983 (or because their router can beat up
my router) that they somehow magically outrank me, and that their opinions
are God and mine are worthless. That's quite obviously horse shit. How
do you have a pecking order anyway in a self-avowed anarchy? Sorry, no.
The two are not compatible. I've got as much right to an opinion as you
do. And until proved otherwise, mine is as valid as your's. And my
opinion is that this sucks. ARIN's attitude sucks. And they are apparently
redefining the word ``fraud'' in a way that will insure that they will
have to do minimal work, and that they'll never ever have to do anything
that might be ``hard'' in the sense of possibly being the lest bit contro-
versial, you know, like telling some hijacker ``Stop doing that.''

Yes, I'm sure that there are a lot of people here who will pipe up and say
that it's just wonderful that ARIN is useless and that ARIN will do nothing.
Their anachronistic anarchist philosophy is not a philosophy. It's merely
an abdication of responsibility, and should be seen as such. It is just
a lazy man's way of avoiding having to think about how a society should
be organized. It is the coward's way of avoiding making rules that some
members of the group might find controversial.

On the net, hijacking of IP space is just about the deepest kind of
violation of the commonly accepted rules of how to behave in this shared
space that I can imagine. And now, the people who _issue_ the IP space
assignments say that they don't care to _police_ the very assignments
that they themselves have made! Well then what's the bleeping point of
even having them or their whole bloody allocation system then? I say
let's disband the Federal Reserve *and* ARIN, because they are all just
a bunch of useless bureaucrats at this point who are serving nobody other
than themselves. If we are going to have anarchy, then bring it on!
Let's not have this half-assed sort of anarchy that we have now. Let's
have the real thing! I'm going out tomorrow and I'm going to buy me the
biggest router than I can afford. Then I'm going to get it colocated
someplace, and then I'm going to start announcing all the routes I feel
like, and nobody will do shit about it... because its not their job man!

And some people still wonder why this planet is so f**ked up. Geeezzz.

Regards,
rfg

P.S. It ain't as if I'm either asking or expecting anybody from ARIN to
take a plane out to that place where the hunters shot down that cable, or
some exchange point in Bumf**k, Idaho, and with guns drawn, physically
pull the wire out of the socket. No. I'm *not* asking for that kind of
``policing''. But Christ! They could at least take a position, instead
of simply standing around with their hands in their pockets. Is that
really too much to ask? They could say, to everyone involved, and to
the community as a whole, ``This ain't right. *We* maintain the official
allocation records. In most cases, *we* made the allocations, and that
guy should NOT be announcing routes to that IP space, and he shouldn't be
announcing anything at all via that AS number, because these things ain't
his.''

That's all. I'd just like to see them maybe take a postion. I'm quite
sure that ARIN corporate counsel has advised them to never take a
position on anything... kind-of like Minister Hacker in "Yes, Minister",
who often hoped that the government could have NO position on anything
the least bit controversial...except with respect to things that might
erode their own power, you know, like the position that IP addresses
are not property, which they try desperately to maintain (against all
obvious facts to the contrary) as a way of keeping courts out of the
business of saying who gets what, so that they can maintain their own
total and absolute sovereignty over this shit, with no annoying judges
to get in their way. But you know, if they won't even take a position
on a bloody blatant hijacking by low life spammer slugs and/or by others
who the spammers have paid Big Bucks to, to steal the space for them,
they really, like I said, what's the point of even having an allocation
``authority''? (And obviously, I am using that term very very loosely
here, because they clearly only care to use their ``authority'' when it
makes everybody happy, and won't use it at all when it might make even
one lone spammer/hijacker sad. If there is a better definition of
cowardice and abdication, I don't know what it is.)

------- Forwarded Message

Replied: Fri, 01 Oct 2010 00:49:08 -0700
Replied: hostmaster@arin.net
Return-Path: hostmaster@arin.net
Delivery-Date: Thu Sep 30 08:30:13 2010
Return-Path: <hostmaster@arin.net>
X-Original-To: rfg@tristatelogic.com
Delivered-To: rfg@tristatelogic.com
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33])
  by segfault.tristatelogic.com (Postfix) with ESMTP id 389DDBDC34
  for <rfg@tristatelogic.com>; Thu, 30 Sep 2010 08:30:13 -0700 (PDT)
Received: by smtp1.arin.net (Postfix, from userid 323)
  id 89AD4165331; Thu, 30 Sep 2010 11:30:07 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.2.5-arin1 (2008-06-10) on smtp1.arin.net
X-Spam-Level:
X-Spam-Status: No, score=-144.2 required=5.0 tests=AWL,BAYES_00,
  FH_DATE_PAST_20XX,USER_IN_WHITELIST autolearn=no version=3.2.5-arin1
Received: from pgp.arin.net (pgp.arin.net [192.136.136.159])
  by smtp1.arin.net (Postfix) with ESMTP id 5F592165324
  for <rfg@tristatelogic.com>; Thu, 30 Sep 2010 11:30:07 -0400 (EDT)
Received: by pgp.arin.net (Postfix, from userid 688)
  id 37E9F1A8069; Thu, 30 Sep 2010 11:30:07 -0400 (EDT)
Received: from shell.arin.net (shell.arin.net [192.136.136.149]) by
pgp.arin.net (Postfix) with ESMTP id AD3C81A8103 for
<rfg@tristatelogic.com>; Thu, 30 Sep 2010 11:30:06 -0400 (EDT)
Received: by shell.arin.net (Postfix, from userid 2006) id C6F5D8059;
Thu, 30 Sep 2010 11:30:06 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by shell.arin.net
(Postfix) with ESMTP id C5B0A8058; Thu, 30 Sep 2010 11:30:06 -0400 (EDT)
X-X-Sender: jonw@shell.arin.net
In-Reply-To: <mailbox-17204-1285704731-754558@shell.arin.net>
Message-ID: <Pine.LNX.4.64.1009301126150.20077@shell.arin.net>
References: <mailbox-17204-1285704731-754558@shell.arin.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

Thanks for your report.

AS11296 appears to have been hijacked.

Separately and additionally, all of the IPv4 blocks currently being
announced by AS11296 appear to have been hijacked also:

63.247.160.0/19
199.241.64.0/19
206.226.64.0/24
206.226.65.0/24
206.226.66.0/24
206.226.67.0/24
206.226.68.0/24
206.226.69.0/24
206.226.70.0/24
206.226.71.0/24
206.226.72.0/24
206.226.73.0/24
206.226.74.0/24
206.226.75.0/24
206.226.76.0/24
206.226.77.0/24
206.226.78.0/24
206.226.79.0/24
206.226.96.0/19

We've looked through these records and can't find any unauthorized
changes. Do you have any further details regarding unauthorized changes
to ARIN's Whois data? If not, we can't take action. We can investigate
fraudulent changes to registration data, but we can't investigate
fraudulent activity related to use of numbering resources (e.g. routing of
resources by someone other than the registrant).

If you have any further questions, comments, or concerns please respond to
this message or contact me directly.

Regards,

Jon Worley
Senior Resource Analyst
ARIN Registration Services

hostmaster@arin.net
703.227.0660

Are you ready for IPv6? For information on transitioning to IPv6, see:

      https://www.arin.net/knowledge/about_resources/v6/v6.html
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFMpKz/ZKymzxl/LaURAvVuAJsFT6DZxoZ5O13SDRKWK6Lkz1yusgCdFt01
aMTBE0O/ucnRx+8rk8+QbEE=
=qqf5
- -----END PGP SIGNATURE-----

------- End of Forwarded Message

2

Ronald,

It's not so much a matter of whether ARIN cares or whether ARIN wants
to do something about your issue. It's more a matter of whether ARIN
is empowered to do anything at all about your issue.

ARIN is a registry. They don't run routers (outside of a small handfull
of them that provide certain ARIN infrastructure). They have no control
over BGP, the routing table, or anything that would be able to do anything
about your particular brand of issue.

What they can do something about is, indeed, things that got into the
registry data through fraud, deceit, error, omission, or other unintended
mechanism.

I'm sorry you're not satisfied with that fact. I'm sorry that you are obviously
clearly very upset by this experience. However, I think your issue stems
from a fundamental misunderstanding of the role ARIN plays in the
community vs. that of the ISPs.

It's kind of like asking a DMV representative to arrest an auto thief.
ARIN does registrations. They aren't the internet police.

Owen

3

In message <B3543192-FB22-4CDC-84D0-2944EA237464@delong.com>,

It's not so much a matter of whether ARIN cares or whether ARIN wants
to do something about your issue. It's more a matter of whether ARIN
is empowered to do anything at all about your issue.

That is complete and utter horse shit, and you're just dodging the real
issue by trying to change the subject. It isn't going to work. People,
even people here, may be stupid, but I think that most can recognize sleight
of hand when they see it.

I'm sorry you're not satisfied with that fact. I'm sorry that you are =
obviously
clearly very upset by this experience. However, I think your issue stems
from a fundamental misunderstanding of the role ARIN plays in the
community vs. that of the ISPs.

No, it doesn't. I think that *your* issue stems from a fundamental inability
to read what I wrote.

It's kind of like asking a DMV representative to arrest an auto thief.

No, it's kind of like asking the DMV whether the car belongs to the thief
or to someone else. They keep the records for Christ's sake! They *can*
take a position on that rudumentary, simple, and basic question, and they
should. And that is all I ask or expect them to do. But they don't
even want to do that miniscule amount of work, apparently. They want to
be the Keeper of the Records, but then they want to roll over and play
dead, or ignorant, or agnostic, whenever somebody has the temerrity to
simply ask them what the f**king records they are keeping *mean* about
who actually owns what.

I already said it, but I'll say it again for the benefit of those with
low reading comprehension. Nobody is asking ARIN to go out, with guns
drawn, and pull the plug themselves. But they can and should take a
position on who owns what. That is a judicial function, not a police
function. If you don't understand the distinction, then you are dumber
than you think I think you are.

Regards,
rfg

4

Come one mate, there's no need to be just outright insulting people.
Sure everyone disagrees on some things, but still...

Lets play out this scenario then. What would you recommend ARIN actually do?
I don't mean 'take a stance' or 'have an opinion', but rather what
process should in your mind they be following?

There are still other avenues. I mentioned in a previous email about
IETF or a working group to come up with ideas and methods to combat
spam and abuse. If you put as much time into one of them as you do
fighting with the spammers directly and ARIN, then you might actually
end up solving the problem at the core!

I really don't want to drag this anti-spam stuff out. There's been a
huge amount of posting these last few days over this (of which I am a
culprit also), but I do think its valuable to hit this nail on the
head. In other words, perhaps other people on this list are getting a
bit fed up with it, so lets just sort it out and quickly..

5

I sent an abuse complaint to Mr. Curran and the abuse helpdesk about a
month or two ago. Took weeks to get an initial response from the
helpdesk and i'm not certain they have actually done anything yet.

Jeff

6

R,
  I have a couple of questions for you...

  perhaps I am unclear here. are you asserting that [natural/legal]
  persons OWN address space?

  Last I checked, ARIN records a binding between a person and a
  "Right to Use" agreement that is reflected in the ARIN database.

  e.g.

  Bills Bait & Sushi has the right to use 168.254.0.0/16
    from 01oct1999 - current(*)

  * registration fees are current.

  ARIN publishes reports from its database in two basic forms,
  the WHOIS (et.al.) format and the [ip6/in-addr].arpa DNS format.

  Are you suggesting that ARIN does _NOT_ publish data or that
  ARIN doesn't keep the data current, or something else?

--bill

7

As to what ARIN can 'do' about addresses that are unused/abandoned and later hijacked...

ARIN delegates Reverse DNS for every allocation that they make. Address blocks that are reported, investigated, and determined to be unused/abandoned could be delegated to special ARIN name servers that merely returned the following for any reverse DNS query:

z.y.x.w.in-addr.arpa. 172800 IN PTR do.not.accept.anything.from.this.abandoned.address.space

This is something that ARIN *could* easily do technically. Admittedly, this would require reporting and investigation that I am uncertain whether or not ARIN is empowered/funded to do. This would also require a process be put in place for removing allocations from the delegation to the unused/abandoned reverse DNS servers...

-DM

8

Goodness me - I've seen that trick before. Worked for
  about 15 minutes before I had legal camped out in the office.
  Pulled it shortly there after.

  I -think- what you are really after is the (fairly) new rPKI
  pilot - where there are crypto-keys tied to each delegated
  prefix. If the keys are valid, then ARIN (or other RIR) has
  "sanctioned" thier use. No or Bad crypto, then the RIR has
  some concerns about the resource.

  the downside to this is that the RIR can effectivey cut off
  someone who would otherwise be in good standing. Sort of
  removes a level of independence in network operations. Think
  of what happens when (due to backhoe-fade, for instance) you
  -can't- get to the RIR CA to validate your prefix crypto? Do
  you drop the routes? Or would you prefer a more resilient
  and robust solution? YMMV here, depending on whom you are
  willing to trust as both a reputation broker -AND- as the prefix
  police.

  The idea is that the crypto is harder to forge. DNS forging
  is almost as easy as prefix "borrowing".

--bill

9

I am not referring to DNS forging or crypto DNS validation or route announcement validation - which are certainly good topics that are worthy of further discussion.

I am merely refuting the statement, which I have heard many times in many different forums, that ARIN (or any RIR) makes address allocations and then walks away with no further active involvement in the use of these allocations. This statement is simply not true.

These sorts of statements about an RIR having no ability to affect prior allocations are normally formed like:
1) RIRs have no control over the routing table or anything operationally in the path of evil people using IPs.
2) An RIR just makes allocations and then has nothing to do with IPs on a daily basis.
3) An RIR is powerless to affect anything operationally (other than reclaiming allocations) for allocations that have been made in the past.

These are all untrue statements. The RIR's reverse DNS servers are queried all day every day for the reverse DNS delegations for every netblock that they allocate. This means that RIRs are, in at least this way, actively operationally involved in the use of the allocations that they make. This also means that an RIR has the technical vector to affect the active present use of the allocations that they have made in the past.

From ARIN's Number Resource Policy Manual [ https://www.arin.net/policy/nrpm.html ]:
...
3.6 Annual Whois POC Validation
   3.6.1 Method of Annual Verification
     During ARINs annual Whois POC validation, an e-mail will be sent to every POC in the Whois database. Each POC will have a maximum of 60 days to respond with an affirmative that their Whois contact information is correct and complete. Unresponsive POC email addresses shall be marked as such in the database. If ARIN staff deems a POC to be completely and permanently abandoned or otherwise illegitimate, the POC record shall be marked invalid. ARIN will maintain, and make readily available to the community, a current list of number resources with no valid POC; this data will be subject to the current bulk Whois policy.
...
7. Reverse Mapping
   7.1 Maintaining IN-ADDRs
     All ISPs receiving one or more distinct /16 CIDR blocks of IP addresses from ARIN will be responsible for maintaining all IN-ADDR.ARPA domain records for their respective customers. For blocks smaller than /16, and for the segment of larger blocks smaller than /16, ARIN can maintain IN-ADDRs.

   7.2 Lame Delegations in IN-ADDR.ARPA
     ARIN will actively identify lame DNS name server(s) for reverse address delegations associated with address blocks allocated, assigned or administered by ARIN. Upon identification of a lame delegation, ARIN shall attempt to contact the POC for that resource and resolve the issue. If, following due diligence, ARIN is unable to resolve the lame delegation, ARIN will update the Whois database records resulting in the removal of lame servers.

So... ARIN has some 'investigation' power and responsibility for actively removing lame POC contacts and Reverse DNS delegations. What isn't clear to me from ARIN's policies is what happens when all POC contacts or all Reverse DNS delegations for an allocation have been removed because they are lame...

This is not to single ARIN out particularly. All of the above is true for every RIR (ARIN, RIPE, APNIC, AFRINIC, LACNIC), though I haven't dug into any policies except ARIN's.

-DM

10

\> I -think- what you are really after is the (fairly) new rPKI

   pilot \- where there are crypto\-keys tied to each delegated
   prefix\.  If the keys are valid, then ARIN \(or other RIR\) has
   &quot;sanctioned&quot; thier use\.  No or Bad crypto, then the RIR has

'or anyone else in the heirarchy of certificates' (nominally: IANA ->
ARIN -> LIR (uunet/701) -> bmanning-inc -> bait&sushi (endsite) )

   some concerns about the resource\.

or someone in the chain forgot to re-gen their cert, do the dance with
resigning and such. (there are a few failure modes, but in general
sure)

   the downside to this is that the RIR can effectivey cut off
   someone who would otherwise be in good standing\.  Sort of

this depends entirely on the model that the network operators choose
to use when accepting routes. Presuming they can, on-router, decide
with policy what to do if a route origin (later hopefully route-path
as well as origin) is seen as invalid/non-validated/uncool/etc, there
could be many outcomes (local-pref change, community marking,
route-reject...) chosen.

   removes a level of independence in network operations\.  Think
   of what happens when \(due to backhoe\-fade, for instance\) you
   \-can&#39;t\- get to the RIR CA to validate your prefix crypto?  Do
   you drop the routes?  Or would you prefer a more resilient
   and robust solution?  YMMV here, depending on whom you are
   willing to trust as both a reputation broker \-AND\- as the prefix
   police\.

hopefully the cache's you run are redundant (or the cache service you
pay for is redundant enough), as well the cache view is not
necessarily consistent (timing issues with updates and such), so some
flexibility is required in the end system policy. (end-system here is
the router, hopefully it is similar across an asn)

I think so far the models proposed in SIDR-wg include:
  o more than one cert tree (trust anchor)
  o the provision of the main cert heirarchy NOT necessarily be the
one I outlined above (iana->rir->lir->you)
  o operators have the ability to influence route marking based on
certificate validation outcomes
  o low on-router crypto work
  o local and supportable systems to do the crypto heavy lifting, kept
in sync with what seems like a reasonably well understood methodology
  o publication of the certification information for objects (asn's,
netblocks, subnets) via existing processes (plus some crypto marking
of course)

   The idea is that the crypto is harder to forge\.  DNS forging
   is almost as easy as prefix &quot;borrowing&quot;\.

and that the crypto/certificates will help us all better automate
validation of the routing information... sort of adding certificate
checking to rpsl? or, for whatever process you use to generate
prefix-lists today for customers, add some openssl certificate
validation as well.

The end state I hope is NOT just prefix-lists, but certificate
checking essentially in realtime with route acceptance in to
Adj-RIB-in...

I believe Randy Bush has presented some of this fodder at a previous
nanog meeting actually?

-chris

11

[..]

I think so far the models proposed in SIDR-wg include:
  o more than one cert tree (trust anchor)

Why not in a similar vain as RBLs: white and black lists.

One can then subscribe to the white & black lists that one trust and
give positive/negative points when an entry appears on one of those
lists, based on the points that a prefix/asnpath combo gets it is either
accepted, rejected or operator-warned.

And the good one of course is that you can setup your own repository and
give that out to your own systems or to other people's, then you just
score your system above the other lists and presto you can overrule
decisions which would be made otherwise.

If you have multiple sources you trust, you are effectively just adding
redundancy to your system, all problems solved. Works for spam, should
also work for this.

Greets,
Jeroen

12

I'm sure someone will think it's a fine plan to set up a TA and sign
down ROA's that indicate 'badness' or 'invalid' or something similar.
There's nothing stopping that, similarly today you COULD subscribe to
a BGP feed of subnets of actually seen routes rewriting the next-hop
to dsc0/Null0/honeypot...

I don't think this sort of thing is in the SIDR-wg's charter though...
much like RBL's are not in DNS-EXT's charter?

-chris

13

So what you're saying is that ARIN should publish data on the rightful users of the number resources in some online database?

(maybe they could call it WHOIS)

14

So what you're saying is that ARIN should publish data on the rightful
users of the number resources in some online database?

(maybe they could call it WHOIS)

--
Dave

So ARIN is in the process of verifying their contacts database.
Organizations with an unreachable contact might be a good place to plant
a "dig here" sign.

Maybe when one of us retires, we could engage in a little research
project as a community service or something. A first step might be
matching ASN resources to unreachable contacts. Then to collect the low
hanging fruit, find the ASNs found above that are NOT in the routing
table and attempt to match those up with organizations and see if those
organizations even still exist. For the ones that obviously no longer
exist, create a report of the ASNs and any other number resources
associated with that organization and provide that information to the
registrar.

Then you go through the ones that ARE in the routing table. Any of
those organizations that are obviously defunct would be the next higher
level of fruit. This would be particularly true if a historical look at
routing information shows the AS was in the table at some point,
disappeared after the organization went defunct, and then suddenly
appeared again in a completely different region of the planet with name
resources pointing to a completely different organization than the
number resources. Then if a suspicious operator is discovered, it must
be reported to their upstream, the registrar with involved with the
number resources, and the community.

See how this goes? It takes someone working on this that has access to
a lot of information and has the time to do it. It also has to be
someone that isn't a "loose cannon" and can dig through it in a
methodical fashion and whether or not "spam" has come from the address
space really has no bearing on the process. At least it has no bearing
on the process up to that point. All that is being done is to "weed"
the database of defunct resources.

So while the DMV doesn't go after car theft, this is more along the
lines of stealing a neighbor's license plate from that old car in the
back field, making a sticker to put on it, and driving around as if it
is a legitimate plate. The DMV records would show who that license
plate belongs to and a police officer in a traffic stop would find out
in short order that the plate is defunct but the database available to
internet operators is so poor that there really is no way to be sure if
the data being returned is actionable or not.

G

15

In message <20101001123356.GA10880@vacation.karoshi.com.>,
bmanning@vacation.karoshi.com wrote:

16

David,

What *is* true is that ARIN's further involvement in the use of those
allocations is regulated by the policies that you and I wrote and
instructed ARIN to follow. Those policies include no actions to be
taken when a hijacker announces routes contrary to ARIN's registry
information. So long as ARIN's information has not been falsified,
forcing or not forcing folks to obey it is left for the ISPs to
resolve for themselves.

Do you think ARIN should should act as a clearinghouse for action with
respect to hijacked BGP announcements? Draft a policy proposal and
post it on the PPML. If your colleagues agree with you, that will
become one of ARIN's roles.

Until then, you criticize ARIN unfairly for doing what you and I have
told it to do.

Regards,
Bill Herrin

17

Ok... thanks for the favor of your reply.

--bill

18

Nope! Apparently, ARIN's fraud reporting form is only to be used for
reporting cases where somebody has fiddled one of ARIN's whois records
in a fradulent way. If somebody just waltzes in and starts announcing a
bunch of routes to a bunch of hijacked IP space from a hijacked ASN
(or two, or three) ARIN doesn't want to hear about it.

Ron -

You note the following:

They could say, to everyone involved, and to the community as a whole,
``This ain't right. *We* maintain the official allocation records.
In most cases, *we* made the allocations, and that guy should NOT be
announcing routes to that IP space, and he shouldn't be announcing
anything at all via that AS number, because these things ain't his.''

At present, ARIN doesn't review the routing of address space to see
if an allocation made to party is being announced by another party.

From your emails, I'm guess that you'd like ARIN to do so.

I've run several several ISPs and a hosting firm, and I'm not quite
sure how ARIN can definitively know that any of the AS#'s involved
should or should not be routing a given network block. There are
some heuristics that will suggest something is "fishy" about use of
a network block, but are you actually suggesting that ARIN would
revoke resources as a result of that?

In those rare
cases where the perp is considerate enough to ALSO fiddle the relevant
WHOIS records in some fradulent way, THEN (apparently) ARIN will get
involved, but only to the extent of re-jiggering the WHOIS record(s).
Once that's been done, they will happily leave the perp to announce
all of the fradulent routes and hijacked space he wants, in perpetuity.

Correct. We will revoke the address space, but I'm uncertain what else
you suggest we do... could you elaborate here?

/John

John Curran
President and CEO
ARIN

19

Ok, it's clear that you're pretty upset about your recent dealings with ARIN. I think you've made that abundantly clear. Having said that, responding to people with snarky insults is not going to advance your position or motivate people to try to help you.

This is my first and only contribution to this thread.

jms

20

EXACTLY.

Ron, what exactly do you expect ARIN to do? Where is the magic wand one would wave to erase routes from the internet? ARIN (in fact NO ONE) has no actual means to block or recend any route announcement. Do you suggest they sue whomever is involved? That won't be very fast, or even an option outside the US.

The only reason this sort of shit happens is because of bad network operators who allow it and participate in it. Responsible operators ask for and verify one's rights to address space before accepting it. (AS path and prefix filtering can only go so far.)

--Ricky