[ARIN-consult] Community Consultation on IRR Route Validation

[Danny McPherson]

On 2015-04-12 11:10, Jo Rhett wrote: 

> As numerous others have
pointed out, other regional IRRs have been successful in similar
efforts.
> 
> FYI: sorry for not speaking up sooner. In case it isn't
obvious from this post, I vehemently support the idea of ARIN
undertaking this effort to improve the ARIN IRR which I utilize at
multiple organizations. Vote in favor.

I agree with Jo and others here.


If you can't squelch the cruft (especially the slew of
proxied-registered stuff that mostly certainly exists, albeit much for
good reason initially, but with bad long-term effects), then you at
least need a mechanism to allow resources holders who actively maintain
their IRR objects (wherever they live, however they're formatted) to
provide an indicator to folks that they can find them there, and that
their upstreams or peers can employ that information for control plane
(&data plane) filtering. 

And because RIRs likely aren't ever going to
be the only ones to operate IRRs (e.g., ISPs that use their own or other
DB formats for internal and external routing provisioning functions)
which is good and bad, methinks, solutions need to be developed to
ensure that resource holders have the capability to specify precisely
where the policy information associated with their number resources live
(e.g., a URI, or something similar) - hence "validated", which could be
nothing more than a pointer. 

Additionally, in this day and age there
also really needs to be some sort of push (pub/sub) model so that
relying parties that are using this information to develop policy can be
informed when adds/mods/dels take place - they shouldn't have to
continuously/periodically discover and enumerate all the structures in
all the feasible IRRs to discover changes they might need to evaluate
and effectuate in their routing policies. 

If you solve this issue then
the stable and secure IRRs will gain market share, IRR hygiene issues
will become more evident (RIRs should lead the pack in cleaniness
because of RIPE-esque techniques), operators can use nearly all the
existing configuration tooling, folks that operate their own IRRs (many
for good reason) can continue, and the same control plane policies
derived for routing can be used to develop feasible path anti-spoofing
policies in the data plane (inter-domain) and help to automate a good
chunk of the BCP38 difficulties that persist and enable reflective
amplification and other attacks. 

Out of the gate you get origin
validation in persistent storage on routers with no new router code or
protocols, and can apply per-peer policies in the control and data plane
like we did in the '90s (mostly the former because spoofing wasn't such
an issue). 

All for linear solutions and reuse here, with mechanisms
that help desk folks can debug, and some sensible means to implement
sufficient operational buffers that protect our network (rather than
tight coupling required by others solutions). 

-danny 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20150416/f5fd03ec/attachment.html>