[Services-wg] SWG IRR discussion

Thu Sep 1 19:04:49 EDT 2016

Couple of thoughts, in case I miss this on the call:

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.

*It feels like ARIN should treat RPKI similar to IPv6 - spend several years
in education + advocacy, slowly ramp up as the industry warrants it. **RPKI
is future thinking, IRR is previous thinking that needs modernization -
they "solve" similar problems but should be decoupled as much as possible.*

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.

>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 *"This looks accurate, please update my IRR records to match"*
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.

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.

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:

   - Produce a high level document which states (consumable by both network
   engineers and management):
      - What IRR's offer (and how they compare to RPKI)
      - 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).
      - Quotes or
      - Real world data (ie: # of prefixes with zero IRR into, # of
      prefixes with "correct" IRR data, # of prefixes with "incorrect"
IRR data,
      etc

   - Product a software requirements document
      - New RPSL language, how would this change, what are the benefits of
      new expressions (say regex's)
      - IRR end-user experiece, say a legacy whois interface and new API.
      Would a new IRRToolkit CLI tool be offered, etc.
      - Migration tool for existing IRR data

On Thu, Sep 1, 2016 at 11:52 AM, Aaron Hughes <aaronh at tcp0.com> wrote:

> SWG Team.
>
> First a bit of history:
>
> 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)?
>
> 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.
>
> This topic was also discussed at a few ARIN board meetings, one snipped
> from minutes:
>
> Snippet from  board minutes:
>
> [snip]
>
> 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.
> 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.
> 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.
> 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.
> It was the sense of the Board to proceed in this direction.
>
> [end]
>
> 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).
>
> 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.
>
> The following was sent out then: (around the formation of the SWG)
>
> [snip]
>
> Here’s the staff report on our IRR consultation, including recommended
>   next steps.  This has been somewhat overtaken by your initiative with
>   respect to ARIN IRR Strategy, but may be useful input (i.e. the default
>   direction we’d head absent any other guidance.)
>
>   While I’ve asked Mark to put this work on hold pending Services WG
>   guidance (and he is quite receptive to same),  one of action items is
>   already underway with other participants from the RIRs and the IETF
>   (specifically, the "Produce a Simplified Profile of RPSL” item) - I
> believe
>   it would be best to have Mark continue his participation in this effort,
>   (unless the Services WG feel otherwise.)
>
>
>
> [end]
>
> There are many options for a way forward, however, I prefer we have the
> discussion on the call tomorrow before I suggest any here.
>
> Please let me know if you have any questions about the history and or
> problem statement.
>
> Looking forward to working with you all.
>
> Cheers,
> Aaron
>
>
>
> --
>
> Aaron Hughes
> aaronh at tcp0.com
> +1-703-244-0427
> Key fingerprint = 6486 43A5 1692 502C DCFC  8446 C714 E317 F6B1 DEC2
> http://www.tcp0.com/
>
>
>
>
>
>
> _______________________________________________
> Services-wg mailing list
> Services-wg at arin.net
> http://lists.arin.net/mailman/listinfo/services-wg
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/services-wg/attachments/20160901/adca2dfd/attachment.html>