[arin-ppml] ARIN validation of authorized contacts

[George, Wes E [NTK]]

Apologies in advance if folks don't view this as policy-related enough. Happy to move the discussion to arin-discuss if it's more 
appropriate for that list instead.

There's a thread on NANOG right now about some address hijacking/squatting, and it brings up an interesting question about how ARIN 
determines whether a person purporting to represent a company is actually authorized to make changes.
That is, how do you prove to ARIN that:
a) you are who you say you are
b) that you are actually an agent for the company you are purportedly representing
c) that you are authorized to request changes on behalf of said company.

The situation where someone poses as an agent of a company (especially one that has let their records/domains lapse) in an effort to 
acquire their address space in a way that looks semi-legitimate (by updating the ARIN records) is mainly an annoyance right now, 
because ARIN usually works rapidly with the proper owners (if exist) to restore the correct contact info.

However, my sense is that as long as the bills get paid and nothing triggers the "spidey sense" of ARIN staff, *accuracy* of records 
is less important than simply having *valid* (reachable) POC records. As we look at the SIDR origin validation implementation, where 
ARIN would be providing Resource Certificates for the rightful owner to originate an announcement of a given block of addresses, I 
think this becomes more than just an annoyance. The expectation is that other announcements that do not have that authority will be 
either rejected or treated with lower priority than the validated announcement in the routing table. But this system is only as good 
as the underlying verification to provide the delegation in the first place. If it's easily gamed, then the veracity of the 
information is suspect and the entire implementation is of limited value as an input to a routing policy decision, not to mention the 
fact that it opens legitimate resource holders up to exactly the type of attack this is trying to prevent.

So my question is regarding the identification and validation of authorized agents. Is ARIN staff already thinking about ways to 
manage this? Can we potentially kill two birds with one stone and improve the accuracy of ARIN whois records and support RPKI? Most 
security authorization systems have a rigidly defined validation procedure, or a web of trust (think PGP key signing parties), or 
both. I'm not by any means a security expert, but I'm wondering if there is a hole in our policy that needs to cover how ARIN manages 
POC verification/authorization? Our policy around DMR POCs does require that the person have an email address that matches the company 
of record, but to my knowledge, even this limited requirement is not enforced for other POCs. Even if it simply documents an existing 
BCP that staff should follow, I would think that this should be part of our policy. Since this isn't strictly an implementation detail 
of the system itself, but rather the process surrounding the system, I think that ARIN is probably the proper place for this, rather 
than as an extension to the SIDR RPKI drafts.
I will also note that there is no existing policy covering ARIN's participation in the RPKI/Origin Validation at all. I'm not sure if 
it's something that should be documented in policy, or whether it's something like the other services that ARIN offers that is largely 
left to staff to determine implementation details.

ARIN info on RPKI: https://www.arin.net/resources/rpki.html

Email on NANOG, for reference:
http://mailman.nanog.org/pipermail/nanog/2011-March/034845.html
http://mailman.nanog.org/pipermail/nanog/2011-March/034849.html

Thanks,
Wes George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6781 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110331/d6949125/attachment.p7s>