On Sun, Jan 9, 2011 at 1:09 PM, John Curran <jcurran@arin.net> wrote:
Please suggest your preferred means of IRR authentication to the ARIN suggestion process: <https://www.arin.net/participate/acsp/index.html> 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.
John, 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 trivially. 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@inconcepts.biz> Sr Network Operator / Innovative Network Concepts