On Sun, Jan 9, 2011 at 10:47 PM, John Curran <jcurran@arin.net> wrote:
Jeff - ARIN does indeed have folks who worry about whether the policy development process is being followed. We also have folks who actually implement the policy and issue number resources.
And we all agree that this is ARIN's primary role, and what ARIN, organizationally, has been built to be good at. This is what members consider when electing the BoT and no doubt drives ARIN's day-to-day business and technical decisions.
is that we also have quite a few folks who have run production operational services both for the Internet and other mission-critical environments.
What does ARIN, as an organization, do that has short-term operational impact on its members? Two things that I am aware of: IN-ADDR.ARPA delegation and IRR. One of these things gives people no reason to complain. The other is demonstrably insecure in a manner that could have really serious, and embarrassing, consequences, both financial for the members, and in terms of peoples' confidence in ARIN.
I'm not surprised that the IRR allows plaintext passwords, but am myself stunned if indeed we require them, since that disallows even a modicum of protection from trivial acts of sabotage. Rather than repeat what lack of information there is on the web site in regards to what forms of IRR authentication is available, I will go determinate the state of reality and post back here asap. At a minimum, we need much clearer documentation, but if more is required, we'll get it fixed asap.
Thanks, I am glad you are now looking into this. To be clear, it's not just "plain text passwords." There aren't any passwords for the majority of objects. The ARIN documentation indicates that only MAIL-FROM is supported. When asked about this, ARIN personnel who respond to rtreg@arin.net reply that yes, MAIL-FROM is the only authentication mechanism supported, and that no, there is no support for passwords (good) or PGP (also good, but too complicated for some users.) This isn't simply an issue of "plain text passwords." Your mechanism is MAIL-FROM, which means the only check that is done on update/add/delete requests is the From: header. The ARIN database, which is publicly mirrored, contains the email addresses that must be used to add/update/delete objects maintained by a given mntner: object. All you have to do to corrupt or erase a record is look up the record you want to corrupt in the IRR, then look up that mntner, then forge an email from the auth: MAIL-FROM listed in that mntner record. It's dead simple and it is not "plain text passwords," it is no passwords at all. The reason I am still posting is I am deeply concerned about the lack of technical and management competence needed to let this happen in the first place. You shouldn't seriously believe that no ARIN staffer ever thought about this, while also believing that ARIN is currently capable of administering RPKI, by its very nature and as its primary goal, to improve operational network security. For this reason, I think your true task is not simply to address the IRR issue, but to change the mentality at ARIN. If you do have technically skilled personnel, something is preventing them from being effective. If there isn't a management or cultural problem stopping folks from speaking up, then, quite frankly, I think you may be greatly over-estimating the technical savvy of ARIN staff. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts