[arin-ppml] ARIN Multiple Discrete Networks Policy

[Jeff Wheeler]

On Tue, Oct 4, 2011 at 2:29 PM, John Curran <jcurran at arin.net> wrote:
>> It still isn't, and won't be, until a significant portion of ARIN IRR
>> mntners change their authentication mechanism.
>
> Correct.  What should be done in this area?

I see several options with different associated headaches.

The most obvious to me is to eliminate email authentication as a
supported choice, and replace the auth: attributes of those mntner
objects with a garbage password.  This would force those mntners to
contact ARIN (or perhaps use your web site automation?) to "reset
their password" before their objects can be modified.  This way, the
current objects will remain in the database; they cannot be
maliciously altered or erased without non-trivial efforts; but it will
create some customer support issues which will add work-load.

Another would be to simply email all the IRR users and beg them to
change their authentication, cautioning them that their IRR data may
be corrupted or erased by malicious persons if they do not take
action.  Again, support issues will happen, because many users are not
knowledgeable enough to handle this without picking up the phone.  At
least you have warned them about the potential for abuse.

I do not think it would be positive at all if ARIN, whose very
existence largely defends us from government interference in
addressing and routing policy, ended up in the newspaper because it
DID NOT PROTECT ROUTING INFORMATION WITH SOMETHING AS SIMPLE AS
PASSWORDS.  If my use of capslock disturbs you, imagine the flurry of
phone calls from clueless reporters that would happen if someone
erased half the ARIN IRR.

> What useful things do you want us to do to "reduce DFZ bloat"  You have
> mentioned that twice but not indicated exactly what you are looking for...

A good starting point would be to have a user-friendly interface to
ARIN IRR.  MERIT RADB has one that is not bad, but it isn't quite
"point and click," which would benefit the droves of less
knowledgeable operators participating in the DFZ today.  It should be
easy to publish correct IRR information.

I would like it if ARIN had a bot that emailed the technical contact
for address spaces when new DFZ advertisements appear (for a sustained
period of time, say a week) that do not match existing IRR data.  A
friendly message with a link to click on so the operator can log in
and update their IRR records would help them maintain accurate
database entries, and as a side-effect, it would inform them of
accidental advertisements.  As you are no doubt aware, it is normal to
build a transit customer prefix-list with "le /24" for all the
relevant route: objects, which in one way makes life a bit easier; but
contributes to the accidental bloat.

Richard's posts on multiple discrete networks is another factor, but
it is one I choose not to care much about, because I think the
accident / stupidity problem is much worse.  I'm not sure Richard
agrees with me and I might be wrong -- his concern may be more
important to fix.  I think the NRPM change that you believe is
necessary to get the result he wants would probably have potential for
abuse, and so I do not know how I feel about this.

> Let's look at some options -
>
>  - Do you want ARIN to alter the way in which it does address allocations
>    so it ties to the state of someone's IRR information?  If so, that

Yes.

I would also like members who are going to announce a /24 to the DFZ
anyway to be able to request a /24.  This should have been done a very
long time ago.  The reason is not difficult to understand -- if a
member is going to announce a /24 and they already know that's what
they are going to do, you can put them into a suitable address space
where there should generally not be any de-aggregates beyond the
nominal allocation boundary, e.g. /20.  This ALREADY HAPPENS for
2002-3 allocations but not because the network will announce a long
route to the DFZ, but because 2002-3 allows them to have a pretty
small allocation and it was the intent of the community to make it
possible to filter garbage /24s and /22s out of other chunks of the
address space.

I further would like members to be able to request de-aggregated
address space for private interconnections, backbone, etc. that they
do not want to belong to a larger aggregate DFZ announcement.  For
example, I don't want a /24 I use for certain circuits to be announced
to the DFZ at all, but I do want DNS authority for it, and require
globally unique numbers for it.  I don't have a RIR /24, I have /20s
and larger.  In order to get this behavior, I have to jump through
some technical hoops which is not always practical or even possible;
or de-aggregate a /20 and not announce the aggregate route, but
instead announce a /21, /22, a /23, and a /24.  I don't do this but I
also don't get the technical benefit of having some globally unique
numbers for interconnection without having them be globally reachable.

I would like ARIN to come out strongly against any de-aggregation at
all in ISP /32s.  If someone needs to de-aggregate, give them more
/32s!  Strongly discourage them from announcing /48s because it will
be necessary for us all to honor these /48s, meaning we cannot simply
filter everything longer than /32 from the relevant chunks of address
space.  If members do not feel like they should receive a bunch of
/32s, then choose a different size and allocate these from special
space.

If we do not do something like the above, the IPv6 DFZ will make IPv4
look great.

>  - If all you want is for ARIN to improve its IRR services in some manner,
>    and expend more budget in this area in the future, explain the feature
>    that you want to me and I'll include it in the next list of objectives.
>    (If you want to do it formally, you can submit the same to the suggestion
>    process - https://www.arin.net/participate/acsp/index.html

As I mentioned above, I would like the ARIN IRR to be user-friendly.
I agree with your idea that it be integrated into the other ARIN
online tools, and was hoping this would indeed be implemented as you
indicated earlier this year.  I would also like the data in it to be
accurate and for rules to exist on what route: objects may be created
by what user -- I don't think I should be able to insert a route:
object with origin: AS65555 unless I am logged in to the web site as
someone with permission to make routes in AS65555.  I also don't think
I should be able to make route: objects for address space that doesn't
belong to me.

I don't think users should even have to understand that they are
making a route: object, I think it should just say, here are the
allocations and assignments for you, and you can make IRR entries to
facilitate BGP routing if you want to.  This system needs to become
more straight-forward so novice operators can take advantage of it.
It doesn't have to come with a deck of cards and pressurized peanuts,
but if IRR is made easy to use, more people will utilize it.  Fewer
ISPs will dump trash routes into RADB (and then never erase them) and
fewer ISPs will just do all this manually.

I further think the ARIN IRR / tools should make it pretty damn easy
to get a prefix-list for a desired as-set or aut-num, in a way that is
machine-readable, so you don't have to download the files, generate
with your own tools, and so on.  It would be pretty nice if it was
easier for transit networks to take advantage of the data that is
there (and hopefully, more accurate and safe!) but this is
surprisingly hard for many of them.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator  /  Innovative Network Concepts