[arin-ppml] ARIN validation of authorized contacts
George, Wes E [NTK]
Wesley.E.George at sprint.com
Thu Mar 31 07:34:20 EDT 2011
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:
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6781 bytes
Desc: not available
More information about the ARIN-PPML