Jeff Wheeler jsw at
Sun Jan 9 17:30:49 CST 2011

On Sun, Jan 9, 2011 at 1:09 PM, John Curran <jcurran at> wrote:
>  Please suggest your preferred means of IRR authentication to the ARIN
>  suggestion process: <>
>  Alternatively, point to a best practice document from the operator
>  community for what should be done here. ARIN's work plan is very much
>  driven by community input, so that's what is needed here.


I appreciate you taking time to respond to this while on vacation.
However, I think we all know that your response is not a "here is how
you tell us what to do," it's a "here is our cop-out response to make
an incredibly simple fix either never happen, or take six months to
make it through the ARIN process."

If you truly do not understand the posts regarding this matter, I will
summarize them for you very simply:
1) ARIN IRR is a tool that has operational impact; service providers
use it to build prefix-lists automatically, and if the data that
underlies those prefix-lists is corrupted, networks that use the ARIN
IRR will see their transit providers stop accepting their BGP
announcements overnight.  This is not a "some database might be
inaccurate but it's okay," problem; it is an operational problem.
Some peoples' networks depend on that data not becoming corrupted.
Specifically, every network that uses ARIN IRR.

2) ARIN IRR has effectively no security for record updates or deletes.
 Anyone who knows how to forge an email From: header can corrupt or
delete part or all of the ARIN IRR database at any time.  ARIN IRR is
the only database that I am aware of without support for at least
password authentication.  The standard toolset supports passwords

3) If not supporting passwords was a business-driven decision, it was
a bad one, but perhaps a mistake born out of ignorance.  If it was a
technically-driven decision by the staff members responsible for
implementing and maintaining the ARIN IRR, those staff members are not
qualified to handle anything of an operational nature, and you would
be well-advised to find jobs for them that don't require any
attentiveness to operational security.

4) The "ARIN process" will almost certainly not be the route taken
when a change eventually arises.  Some black hat will eventually
decide it would be a clever prank to erase or corrupt the entire
database, and you will then be faced with three choices; a) implement
passwords immediately and not allow any updates from users who haven't
selected one; b) make the ARIN IRR read-only and effectively make it
useless; c) ignore the problem, at which point no ISPs will be willing
to mirror the ARIN IRR anymore, because its data is a liability, not
an asset.

I appreciate that there is a process to go through for proposing ARIN
policy changes, etc.  Your suggestion that this be used when
addressing an operational security matter is foolish and provides
plenty of ammo for people who say ARIN is ineffective (or worse.)

I suggest you take a moment to think about what the news coverage
might be if this eventually blows up in a big enough way to interest
news people.  If a bunch of ISPs go down overnight due to an ARIN
oversight, will some savvy reporter ask himself who at ARIN knew they
were running an operationally-important service with no security
mechanism at all?  Will he have much trouble finding out about a
mailing list discussion in which the CEO of ARIN glazed over the issue
and referred a whistle-blowing person to the ARIN policy process?
Will he then ask if ARIN is an effective steward of RPKI?  Will his
article assign blame to you personally?  Will he draw some link to
"Chinese interception of 15% of the Internet?"

Who knows how mainstream press would interpret such an event, if it
was big enough to attract attention.  If I were you, though, I would
not want my signature at the bottom of an email essentially telling
someone to go post on the correct mailing list.

I suggest you don't be the ARIN CEO that gets mud in his eye because
he didn't understand the value of a password over mail-from.

Jeff S Wheeler <jsw at>
Sr Network Operator  /  Innovative Network Concepts

More information about the NANOG mailing list