Once upon a time, NSI handled both domain names and network addresses.
NSI originally only checked the sender of the e-mail address matched its
database. Spoofing the sender of an e-mail address is/was trivial, and
eventually several domain names were hijacked by other unauthorized
individuals.
NSI added "Guardian" to their template process. Guardian permitted the
points of contact (NIC-Handle) for objects in the NSI database to add a
password (and allegedly a PGP key) to their records. Only templates using
the correct password would be processed. Since NSI handled both names and
numbers, a password on NIC-Handle protected both names and networks.
ARIN was formed, and the duties associated with IP numbers (AS and IP
addresses) were transfered to the new ARIN. However, Guardian or some
alternative didn't seem to get transferred. So we're back to anyone
who can spoof the point of contacts e-mail address can make changes
to the ARIN records.
Is it time for ARIN to re-add security to their database update
procedures?
Sean,
Many good points here. On a related topic, IMHO, NSI needs to take a
step back and evaluate their domain/account management system. The
web-gui system in place now is truly the bastard child, leaving
subscribers with dozens (or hundreds) of domains, each with an
individual account number and no password (or challenge phrase).
I wonder how many virgin goats would need to be slaughtered at the
altars of Tenochtitlan to bring back the email forms 
Regards,
Christopher J. Wolff, VP CIO
Broadband Laboratories, Inc.
http://www.bblabs.com
ARIN was formed, and the duties associated with IP numbers (AS and IP
addresses) were transfered to the new ARIN. However, Guardian or some
alternative didn't seem to get transferred. So we're back to anyone
who can spoof the point of contacts e-mail address can make changes
to the ARIN records.
Is it time for ARIN to re-add security to their database update
procedures?
That won't fix the immediate problem of hijacking legacy prefixes with
expired domains for contacts.
The most simplest, quickest, and easiest fix for this would be for ARIN to
strip or mark as unusuable the email address of any contact in their
database with an expired domain.
Even in the case where the expired domain is a mistake, marking the
contact invalid doesn't have adverse affect because it doesn't change the
status of the allocation, and ARIN can provide a way to resubstantiate the
email address by providing proof (i.e. documentation that is the same as
the original documentation provided for the initial allocation).
Also it would make it really obvious that there was a problem if a
customer requests to announce a prefix with a marked invalid contact.
Mike.
+----------------- H U R R I C A N E - E L E C T R I C -----------------+
The most simplest, quickest, and easiest fix for this would be for ARIN to
strip or mark as unusuable the email address of any contact in their
database with an expired domain.
Technically this is not so easy. The only way to implement it for sure is
to get whois dump from verisign-grs and this they do not allow. A way
around is getting .com, .net, .org zone files and look for any domains
that are deleted or changed to list no dns servers (this happens before
being deleted), but some registrars do not do this (i.e. delete dns
servers from domain) and may even retain the domain for themselve putting
it on special buy list for their other customers.
I'll try to do this myself as described above for domains that are possibly
being deleted in .com, .net, .org and that have any associated arin whois
contacts as sidetrack of larger project, you'll probably hear about it in
6 months. I'll also try a different way by just doing individual whois
checks for all arin contacts for old blocks and then periodically checking
on those domains with whois (this I maybe able to implement sooner actually).
I'm not sure what to do with this data though (i.e. when I found contacts
with deleted domains). I doubt if ARIN would accept or do anything about
it it even if I send it to them.
But this is part of larger issue and leaves too many open doors - i.e. how
would you deal about domains that change hands and not through being
"expired"? Or about non .com/.net/.org domains?
BTW: For those who do not know - ARIN is planning to do more about
authentication, first will come S/MIME X.509 email authentication, other
types of authentication are also planned. I'v no idea when they will get
it done, but I doubt it authentication would be seriously 2 years from
now, so this is generally for very long-term future.
Here here, and if there was a means to see this easily via whois that would
be perfect. Just one small step to add to the announcement verification
process. Perhaps something to do with the autoresponder where if the
contact doesn't respond say yearly or over some time period the contact gets
flagged as in question. Also perhaps the fact that the space is announced
or not and if withdrawn some timer could be set to flag after months or some
appropriate time. It seems that something additionally could be done.
Rather than trying to define expire domains and tracking them, it
may be easier for ARIN to simply send email to the address listed.
If the delivery fails (possibly even request updates/confirmations/etc),
the record can be marked stale/unconfirmed/questionable/whatever.
Additionally, we can consider policy that requires special handling
of changes for records that have been marked non-responsive.
-ron