From aaronh at tcp0.com Thu Sep 1 14:52:31 2016 From: aaronh at tcp0.com (Aaron Hughes) Date: Thu, 1 Sep 2016 11:52:31 -0700 Subject: [Services-wg] SWG IRR discussion Message-ID: 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 201605-ARIN-Staff-IRR-Report-final.pdf Type: application/pdf Size: 104247 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at peterson.org Thu Sep 1 19:04:49 2016 From: matt at peterson.org (Matt Peterson) Date: Thu, 1 Sep 2016 16:04:49 -0700 Subject: [Services-wg] SWG IRR discussion In-Reply-To: References: Message-ID: 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 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: From aaronh at tcp0.com Fri Sep 2 15:05:50 2016 From: aaronh at tcp0.com (Aaron Hughes) Date: Fri, 2 Sep 2016 12:05:50 -0700 Subject: [Services-wg] WebEx information reminder Message-ID: <20160902190550.GI28953@services1-scz.tcp0.com> https://nro.webex.com/nro/j.php?MTID=m16d47f83edd0d6bd83d204fd2543be70 Meeting number (access code): 801 516 717 Meeting password: SWG321 -- Aaron Hughes aaronh at tcp0.com +1-703-244-0427 PGP Public Key ID: 0xF6B1DEC2 Key fingerprint = 6486 43A5 1692 502C DCFC 8446 C714 E317 F6B1 DEC2 http://www.tcp0.com/ Request a meeting with me: https://doodle.com/aaronh From matt at peterson.org Fri Sep 2 15:43:28 2016 From: matt at peterson.org (Matt Peterson) Date: Fri, 2 Sep 2016 12:43:28 -0700 Subject: [Services-wg] Fwd: CKN23-ARIN thread In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Leslie Nobile Date: Thu, Aug 25, 2016 at 1:58 PM Subject: Re: [Services-wg] CKN23-ARIN thread To: Matt Peterson , "services-wg at arin.net" < services-wg at arin.net> Hi Matt- Last modified does not mean last validated. Example: ABC123-ARIN validated her POC handle 5/1/2016. This validation would have updated the last modified date in Whois as 5/1/2016. Her phone number changed, so she modified the POC handle on 8/1/2016. The last modified date would now be 8/1/2016 based on the update to the phone number. We don?t separately track last validation date, so there?s no way to get that currently. Just as an FYI, we are working on enhancements to the entire POC validation process over the next few months and being able to track the actual POC validation date is one of the things I would like to add to our project planning. Leslie From: on behalf of Matt Peterson < matt at peterson.org> Date: Thursday, August 25, 2016 at 2:54 PM To: "services-wg at arin.net" Subject: [Services-wg] CKN23-ARIN thread Of the options, #3 seems useful to clearly advertise Legacy holders - also fixing the database without community input is bad, reverting would show better community engagement. Out of curiosity, does "Last Modified" also mean "Last validated" - as in a POC validation with ARIN Online? --Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From daveid at panix.com Mon Sep 12 13:05:53 2016 From: daveid at panix.com (David R Huberman) Date: Mon, 12 Sep 2016 13:05:53 -0400 (EDT) Subject: [Services-wg] CKN23-ARIN thoughts In-Reply-To: <20160831205246.GN28953@services1-scz.tcp0.com> References: <20160831205246.GN28953@services1-scz.tcp0.com> Message-ID: WG and staff, I have re-reviewed the CKN23 document, and in light of our call, here are my final thoughts: 1) I agree with Matt that hijackers are more normally going to use Whois to verify what they already know: that a block is abandoned and ripe for their misuse. 2) If, as reported by staff, ARIN is receiving 5-10 calls a week on this, that doesn't seem like a "problem" to me. Rather, it seems like CKN23-ARIN is working as intended. It's causing registrants to contact ARIN and, unwillingly or not, learn how to update their registration information. I see this as highly valuable to the community -- more up-to-date contact information is good. If the registrant who contacts ARIN to complain does not ultimately update their information, then I can only assume it either wasn't important enough of a problem to them to actually do anything about it, or perhaps they really shouldnt be listed :) 3) Formally, I support Option #1, the do nothing option. But I can support Option #3, reinstating old resource tech POCs back to the resource, but locking to prevent them from making rDNS changes without validation. Thank you, David