<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">

<html><body style='font-family: Verdana,Geneva,sans-serif'>

<p>On 2015-04-12 11:10, Jo Rhett wrote:</p>

<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->

<pre>

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.

</pre>

</blockquote>

<p> </p>

<p>I agree with Jo and others here. </p>

<p>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.  </p>

<p>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.</p>

<p>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.</p>

<p>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.  </p>

<p>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).  </p>

<p>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).</p>

<p>-danny</p>

<div> </div>

</body></html>