ARIN Fraud Reporting Form ... (Resource listings yes, resource routing no)

John Curran jcurran at arin.net
Sat Oct 2 02:40:33 UTC 2010


On Oct 1, 2010, at 8:08 PM, Ronald F. Guilmette wrote:
> 1)   You folks _are_ already (apparently) making some efforts... at least
> as of this last summer, but perhaps also earlier... to ``validate'' (is
> that the word you would use?) POC contacts.  I know because I've lately
> seen quite a number of your POC contact records (from the WHOIS data base)
> that have a very helpful annotation attached to them, saying quite
> directly and explicitly, that ARIN has been unable to verify or make
> contact with this POC or that POC.  So you are already passing judgement
> on the validity and/or probable invalidity of things in your data base.

Yes, we're attempting to validate contacts per the policy which the
community set (ARIN Network Resource Policy Manual, section 3.6 - 
https://www.arin.net/policy/nrpm.html#three6)

> And more, you are making your determinations public, via the data base
> itself.  I'm not quite sure how it constitutes such a big leap to merely
> extend what you are already doing in the way of validating POCs and just
> impute the exact same level of confidence, or lack thereof, to IP block
> and/or AS records which are associated with unverifiable/uncontactable
> POCs... a set which you are already making serious efforts to delineate
> anyway.

We will shortly be providing a "list of number resources with no valid POC"
for those who desire it (per the current bulk Whois policy.)

> If you can put an annotation into a whois records for a POC,
> saying explicity that you can't get ahold of this person, then it would
> seem to me to be a rather trivial matter of programming to transplant
> a very similar sort of annotation into each and every IP block or AS
> record that has that same specific POC record as one of its associated
> POC records, either Admin, or Technical, or whatever.

Also a nice idea, and one that I've taken as a formal suggestion for
improvement.

> ...
> 
> 2)  You are already (apparently) processing _some_ certain flavors of
> ``fraud reports''  that come in to you via that nice fancy web form you
> folks built and put up on the ARIN web site... you know... the one with
> the nice (and misleading) introduction that entices people like me to
> take the time to use it enter reports about incidents that have traditionally
> been called around these parts ``hijacking''.
> 
> (Note:  That's the word that _you_ used on your web site to say what
> should be reported via the form.  Was I a fool to take you at your word?
> Let me be clear... I am *not* *not* *not* encouraging you to simply
> redact/delete that word from your web site.  No no!  Rather I hope to
> encourage you/ARIN to actually accept and at least investigate reports
> of _all_ flavors of what we around here used to call good old fashioned
> ``hijacking'', regardless of whether the perp was gracious enough to
> also make your choice clearer by dicking with the relevant WHOIS records
> or not.)

Your understanding of our fraud process is correct, and presently the only
form of "hijacking" which we have the ability to correct is address blocks
where the organization have been changed contrary to policy.  To address
your follow-on question, our determinations are indeed definitive and we
correct the WHOIS database accordingly.

> I think you can see where I'm going with this.  You have, I think, tried to
> demur (is that the right word?) on ARIN's behalf, from _either_ investigating
> or, subsequently, from issuing any kind of ``determination'' as regards to
> whether a given block is being routed by the party or parties who ought to
> be routing it, or by some uninvited interloper.

Incorrect.  We determine whether an entry for an address block in WHOIS has
been changed contrary to community-adopted policy.  This means carefully 
reviewing the information supplied on the associated change requests and
various corresponding public records.  *None of it related to whether a 
given party should be routing a given address block*

> ...
> So no, please *do not* go around ``revoking resources''... whatever the hell
> that means.  Certainly, if some half-dead, left-for-dead dot-bomb company
> has a /18, and if your records still say that they have a /18, then they still
> have a /18.  Period.  And if then, some hijacker punk criminal comes along
> and starts routing that /18... well... he's a shmuck, and ought to be dealt
> with.  But the old Dot-Bomb semi-defunct company still does ``own'' (please
> excuse my use of that terminology, which I'm sure you won't approve) that
> block.  So you shouldn't be ``revoking'' anything.  That's not what any of
> this is about.

Semi-defunct firms may hold address blocks, but address blocks assigned to 
fully defunct organizations are returned to the free pool per community 
policy.

> All I want from ARIN, and all I expect from ARIN, in cases like these are
> (a) at least some willingness and effort expended to investigate and (2)
> at least *some sort* of (perhaps minimalist) public statement to the effect
> of ``Look folks, we've looked at this, and in our opinion, what's going on
> here just doesn't look kosher.''

The good news is that if you're referring to investigation of errant entries
in WHOIS, we currently do expend effort to investigate and correct.  In order 
for ARIN to investigate and annotate address blocks according to their state
in the routing tables, it would take a very clear mandate from the community. 
You can suggest such a policy if you feel strongly about this; the process to
to so is shown here: https://www.arin.net/policy/pdp_appendix_b.html

/John

John Curran
President and CEO
ARIN



More information about the NANOG mailing list