<div dir="ltr">Couple of thoughts, in case I miss this on the call:<div><br><div>RPKI is going to be a challenge for the foreseeable future, purely from an technical implementation prospective - routers will need modern software. Asking the overall service provider community to upgrade for an unproven benefit is difficult. This doesn't even factor in learning a new PKI standard which isn't really aligned to say how SSL certificates work (this is well understood, just google for "apache ssl certificate") - education is needed.</div><div><i><br></i></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><i>It feels like ARIN should treat RPKI similar to IPv6 - spend several years in education + advocacy, slowly ramp up as the industry warrants it. </i><i>RPKI is future thinking, IRR is previous thinking that needs modernization - they "solve" similar problems but should be decoupled as much as possible.</i></div></div></blockquote><div><div><i><br></i></div><div>IRR is quite powerful in that existing routing software can take advantage of off-box developed route-maps (or equivalent). The challenge has been 1) proving the value (didn't prevent famous YouTube prefix advertisement) 2) education 3) implementation.</div><div><br></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div>From the staff report, the biggest gap seems to be offering a "auto pilot" mode. Essentially, offer a similar service as "Hosted RPKI" - as in ARIN offers an ARIN Online tool which looks at allocated prefixes and what's in the table.. say a version of IRR Explorer that prints back green or red, but offers a <i>"This looks accurate, please update my IRR records to match"</i> button. Many of the <$10M/yr ISP's I work with are in support of better routing protection mechanisms, but don't have the resources to develop their own IRR knowledge - they just want a "solve this for me" button.</div></div></blockquote><div><div><br></div><div>I would be a little concerned that the "IRR guru's" meeting would fall short without end-user representation. It would be very interesting to survey large IRR users which are not well known tier 1 ISP's that are IRR users (NTT and Level3 come to mind) - but instead say large IXP peering organizations. Some IXP's have even offered IRR and RPKI aware route servers, how has their membership responded to these implementations? Have any false positives occurred, what education was required? etc.</div><div><br></div><div>Not sure (initially) an RFC is the appropriate output for the IRR guru meeting. That's not really an accepted approach anymore (ie: rise of github, OCP, etc), working code and rough consensus leads to great standards - not the other way around. An alternative agenda:</div><div><ul><li>Produce a high level document which states (consumable by both network engineers and management):</li><ul><li>What IRR's offer (and how they compare to RPKI)</li><li>Stated problems, but technical and policy wise in current IRR landscape (my guess each person has a different nit with IRR, mine for example is getting a recycled ASN from ARIN and not being able to get ahold of anyone at Savvis to remove stale entries).</li><li>Quotes or</li><li>Real world data (ie: # of prefixes with zero IRR into, # of prefixes with "correct" IRR data, # of prefixes with "incorrect" IRR data, etc</li></ul></ul><ul><li>Product a software requirements document</li><ul><li>New RPSL language, how would this change, what are the benefits of new expressions (say regex's)</li><li>IRR end-user experiece, say a legacy whois interface and new API. Would a new IRRToolkit CLI tool be offered, etc.</li><li>Migration tool for existing IRR data</li></ul></ul></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 1, 2016 at 11:52 AM, Aaron Hughes <span dir="ltr"><<a href="mailto:aaronh@tcp0.com" target="_blank">aaronh@tcp0.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>SWG Team.</div><div><br></div><div>First a bit of history:</div><div><br></div><div>This topic has been brought up many times in several forums. Roughly: Why is the ARIN region different than other regions and why are there so many 3rd party IRR services. How do we get better, more accurate, consistent, data from IRR service(s)?</div><div><br></div><div>There are a few different approaches to solving the underlying IRR issue, but none of them result in a single solution incorporating authentication, attestation, best current operational practices, cleanup, and a common way forward for all participating registry services. </div><div><br></div><div>This topic was also discussed at a few ARIN board meetings, one snipped from minutes:</div><div><br></div><div>Snippet from  board minutes:<br><br>[snip]<br><br>6. Internet Routing Registry (IRR) Route Validation Consultation. The President noted that there had been an IRR for some time in the ARIN region, but it was one of many, and not as popular as other IRR services for the other RIRs. The President stated ARIN’s routing registry was based on an older version of RIPE’s IRR code base, but that differing architectures made difficult the use of external code and of interfacing it to existing systems. A consultation had been submitted for ARIN membership’s feedback on whether a new IRR was needed, including questions about the functionality of any new IRR development. The President reviewed the positive response of the ARIN community to the project and the potential level of effort needed to undertake it. The President asked the Board for their sense of whether or not to move forward with this project.<br>Aaron Hughes suggested it would be useful to have a global IRR software toolkit that would allow people to more easily interface to the IRRs. He strongly believed this could be accomplished by gathering a select few individuals who were very knowledgeable in developing this type of software, many of whom he personally knew.<br>The President stated that ARIN intended to perform cross-RIR validation. Bill Woodcock suggested identifying the individuals to do this, funding their travel and accommodation to Washington DC in the next 8-12 weeks, and holding such a meeting per Mr. Hughes’ suggestion. The President requested that Mr. Hughes provide him a draft of the invitation for distribution.<br>Bill Woodcock stated that one of the deliverables would be a draft Request For Comment (RFC). For clarity, the President asked what the RFC would be for, specifically. Bill replied that it would be for a modernized RPSL Interchange Format. Aaron Hughes added it would also be for ease of filtering, based on IRR validation. Bill Woodcock further suggested an API, or protocol, that data will move back and forth.<br>It was the sense of the Board to proceed in this direction.<br><br>[end]<br></div><div><br></div><div>At that time, I started discussing this with a few key people in community. Job Snijders, Jared Mauch, Andrew de la Haye, Mark Kosters and the like.. There was positive feedback that it would make sense to write some new RFCs to build standards for all RIRs and all IRR services to follow. This approach would require a great deal of thought on how to solve the authentication, attestation requirements, and less but some thought around RPSL and other IRR standards. The discussions, however, became far more challenging when talking about the feasibility of RKPI ever being implemented and weather or not we should take Secure Routing on as part of the Score of Work. The conversations broke down in great part due to the project not being managed well. (I was light on available time).</div><div><br></div><div>At the same time, (due to lack of progress from outside parties), ARIN staff worked on a proposal to address the IRR issue from an ARIN perspective.</div><div><br></div><div>The following was sent out then: (around the formation of the SWG)</div><div><br></div><div>[snip]</div><div><br></div><div>Here’s the staff report on our IRR consultation, including recommended<br>  next steps.  This has been somewhat overtaken by your initiative with<br>  respect to ARIN IRR Strategy, but may be useful input (i.e. the default<br>  direction we’d head absent any other guidance.) <br><br>  While I’ve asked Mark to put this work on hold pending Services WG<br>  guidance (and he is quite receptive to same),  one of action items is<br>  already underway with other participants from the RIRs and the IETF<br>  (specifically, the "Produce a Simplified Profile of RPSL” item) - I believe<br>  it would be best to have Mark continue his participation in this effort,<br>  (unless the Services WG feel otherwise.)</div><div><br></div><div></div></div><br><div style="word-wrap:break-word"><div></div><div><br></div><div>[end]</div><div><br></div><div>There are many options for a way forward, however, I prefer we have the discussion on the call tomorrow before I suggest any here. </div><div><br></div><div>Please let me know if you have any questions about the history and or problem statement.</div><div><br></div><div>Looking forward to working with you all.</div><div><br></div><div>Cheers,</div><div>Aaron</div><div><br></div><div><br></div><br><div>
<div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><span style="border-collapse:separate;color:rgb(0,0,0);font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;border-spacing:0px"><div style="word-wrap:break-word"><span style="border-collapse:separate;color:rgb(0,0,0);font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;border-spacing:0px"><div style="word-wrap:break-word"><div><div>-- </div><div><br></div><div>Aaron Hughes</div><div><a href="mailto:aaronh@tcp0.com" target="_blank">aaronh@tcp0.com</a></div><div><a href="tel:%2B1-703-244-0427" value="+17032440427" target="_blank">+1-703-244-0427</a></div><div>Key fingerprint = 6486 43A5 1692 502C DCFC  8446 C714 E317 F6B1 DEC2</div><div><a href="http://www.tcp0.com/" target="_blank">http://www.tcp0.com/</a></div><div><br></div></div></div></span></div></span><br></div><br><br>
</div>

<br></div><br>______________________________<wbr>_________________<br>
Services-wg mailing list<br>
<a href="mailto:Services-wg@arin.net">Services-wg@arin.net</a><br>
<a href="http://lists.arin.net/mailman/listinfo/services-wg" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/services-wg</a><br>
<br></blockquote></div><br></div>