From info at arin.net Tue Jan 9 16:27:58 2018 From: info at arin.net (ARIN) Date: Tue, 9 Jan 2018 16:27:58 -0500 Subject: [ARIN-consult] ACSP Consultation: ARIN Internet Routing Registry (IRR) Roadmap Message-ID: <762a5e1c-bf8a-d43a-531a-8b31276de92a@arin.net> Over the last several years, ARIN has received multiple ARIN Consultation and Suggestion Process (ACSP) requests and fielded many customer suggestions about our existing Internet Routing Registry (IRR), and as a result, a community consultation was issued to gauge community interest for ARIN to take on the project of improving this service. The consensus response was that the community would like ARIN to: * Improve the validity of the IRR data * Work with the other RIR's on authorization schemes * Provide appropriate proxy registration services * Integrate/validate with the registration database To accomplish these goals, we anticipate that this work effort will involve a fair bit of community involvement (RIR communities, IETF, and operational forums such as NANOG and CaribNOG) in order to create the appropriate incremental upgrades to the IRR. We are opening a new Community Consultation to solicit feedback on the ARIN IRR Roadmap, detailed below. Please provide comments to arin-consult at arin.net. This consultation will remain open through 5:00 PM EST on Friday, 9 February 2018. Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) *ARIN IRR Roadmap** ** **Background* In response to multiple ACSPs regarding IRR route validation (i.e. the function whereby route objects are validated via the authorization of the appropriate number resource holder), ARIN conducted an IRR community consultation in April 2015. This consultation was opened because the issues around IRR route validation are complex, and implementation was anticipated to exceed the cost of most ACSP implementations. Within the consultation, the ARIN community was asked three questions: * Should ARIN begin a new project to enable IRR route object validation to the ARIN registry database? * If yes, should this effort be coordinated with other RIRs to help facilitate cross-registry authentication? * If yes, should this effort also support third party IRR route object authentication? There were eighteen individual participants in the consultation. Thirteen were in favor of ARIN creating a more robust IRR, two were publicly against, and three were unclear in their support or opposition. Nine participants expressed support for efforts to facilitate inter-RIR authentication, and eight participants expressed support for 3rd party or proxy registrations for authentication of route objects. Two participants suggested ARIN provide facilities for authentication/authorization or delegation to IRRs not operated by an RIR. Several participants had concerns regarding the implementation of an ARIN-validated IRR. Three noted ARIN's past experience with the implementation and cost of RPKI with respect to both community adoption and opportunity-cost, and one participant expressed concerns for contractual obligations that ARIN may place on resource holders provisioning information in a validated IRR. *Implementation Experience Regarding ARIN's Current IRR* ARIN initially setup a RIPE-based IRR years ago. Over the years, we upgraded it based on ACSP suggestions: IPv6 support was implemented in December 2009, and PGP support with additional notifications was released in September 2011. In both of these releases, we replicated the original approach of using the RIPE database software system with loose coupling to our mainline ARIN Online registry system. These upgrades did allow for additional functionality, but it came at a very substantial cost of time and unanticipated functionality issues related to the upgrades. When we undertook these upgrades, we chose to continue the separation in the hopes of doing minimal environmental changes to ARIN's infrastructure to add the suggested improvements. However, the RIPE codebase was not modularized, with significant dependencies on RIPE environment, and consequently was not ideal for use in ARIN's environment. One consequence was the repeated need to pull down the latest release from RIPE, adjust the environment for their software to work, make changes to it to allow functionality that we support, remove out dependencies to resource checks that would not exist in our system, and add dependency links to our system. This has been a very labor-intensive process and it took a lot of engineering time to make the system work. Adjusting to each upgrade from RIPE has also been challenging because of innate differences our database structures. RIPE had two systems ? one being a front-end database and the other being a back-end database with manual synchronization between these two systems. At ARIN, we have just one system that is placed behind the firewall and replicated out to the publically available ARIN slaves as changes are made. The RIPE IRR codebase provided for limited information to be shared to slaves via its replication schemes. Given that ARIN's publically available interface is a slave, the output available to our community was not the same as our internal master, and has resulted in some confusion for ARIN IRR users. ARIN Registration Services Department also has challenges providing customer support to IRR users. Common problems include: * Maintainers not being notified upon changes * Cryptic responses to pgp-validation errors * General lack of customer support features It was our hope that code re-use would save time and money. Unfortunately, this was not the case, and the result was an awkward, difficult-to-operate, and user-unfriendly system that requires considerable engineering time to maintain. It should also be noted that the IRR codebase in use by ARIN is no longer supported or maintained by the RIPE NCC, as they have since completely rewritten their IRR software. *Proposed Roadmap* Given the community feedback received in the consultation, and with due regard to the past experience with reusing code for IRR software, ARIN staff proposes a "ground-up" implementation of a validated IRR that will better integrate with ARIN's current web portal, provisioning system, and other registry functions. This path forward will be a multi-phased approach and will rely on community?defined specifications and global RIR community consensus. This approach will allow ARIN to field a routing registry incrementally, providing utility to the community much sooner than a monolithic "big-bang" release, and it will provide the community an opportunity to provide feedback with respect to features and cost as the project progresses. * Produce a Simplified Profile of RPSL: Most of the complexity of RPSL comes from routing registry features rarely used by the community. To reduce the implementation costs around data modeling and parsing of complex RPSL structures, ARIN will work with the operational community to identify the most commonly used features of the language, and this subset will be documented as an simplified RPSL profile to be used to guide development efforts. * Schedule Frequent Deployments: ARIN will adopt "continuous deployment" strategies to allow for more frequent deployments, similar to the strategy used today in development of the ARIN Online registry system. This will allow the community to use new features of the IRR as they are developed. * Collaborate on Cross-RIR Authentication: ARIN will work with the other RIRs engineering coordination activities to create an appropriate mechanism for authentication and authorization of routing registry objects for which the resources cross regional boundaries. * Provide an Easy IRR integration tool within ARIN Online: ARIN will provide an simple tool within ARIN online for those users who wish to explore the routing of their existing number resources and after successful review, automatically update their corresponding IRR records to match existing routing. * Migrate Data to the New IRR: Where possible, ARIN will create tools and practices to help migrate data from the existing IRR to the new IRR under the authority of resource holders in the ARIN registry. * Cooperate on Standards and Best Practices: Where applicable and appropriate, ARIN will work with the IETF and the other RIRs on documenting any resulting operational standards, profiles, and best practices. We do feel that this effort, once deployed, will help improve routing coordination that exists on the Internet today. The proposed new ARIN IRR will provide a clear and consistent path to allow ISPs to share their routing policies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daveid at panix.com Tue Jan 9 16:40:10 2018 From: daveid at panix.com (David R Huberman) Date: Tue, 9 Jan 2018 16:40:10 -0500 (EST) Subject: [ARIN-consult] ACSP Consultation: ARIN Internet Routing Registry (IRR) Roadmap In-Reply-To: <762a5e1c-bf8a-d43a-531a-8b31276de92a@arin.net> References: <762a5e1c-bf8a-d43a-531a-8b31276de92a@arin.net> Message-ID: Hello, In the Proposed Roadmap, there is a bullet point: > * Migrate Data to the New IRR: Where possible, ARIN will create tools > and practices to help migrate data from the existing IRR to the new IRR > under the authority of resource holders in the ARIN registry. I'm inferring from this that there will essentially be * irr.arin.net * new-irr.arin.net Both IRR directories will run for a period of time. Is that accurate? Or is the intention to populate the new IRR's data, stand it up, and similtaneously retire the existing IRR? Thank you, David From job at ntt.net Tue Jan 9 16:52:04 2018 From: job at ntt.net (Job Snijders) Date: Tue, 9 Jan 2018 21:52:04 +0000 Subject: [ARIN-consult] ACSP Consultation: ARIN Internet Routing Registry (IRR) Roadmap In-Reply-To: <762a5e1c-bf8a-d43a-531a-8b31276de92a@arin.net> References: <762a5e1c-bf8a-d43a-531a-8b31276de92a@arin.net> Message-ID: <20180109215204.GM31128@vurt.meerval.net> Dear ARIN, Where do I sign up to help? Kind regards, Job On Tue, Jan 09, 2018 at 04:27:58PM -0500, ARIN wrote: > Over the last several years, ARIN has received multiple ARIN Consultation > and Suggestion Process (ACSP) requests and fielded many customer suggestions > about our existing Internet Routing Registry (IRR), and as a result, a > community consultation was issued to gauge community interest for ARIN to > take on the project of improving this service. The consensus response was > that the community would like ARIN to: > > * Improve the validity of the IRR data > * Work with the other RIR's on authorization schemes > * Provide appropriate proxy registration services > * Integrate/validate with the registration database > > To accomplish these goals, we anticipate that this work effort will involve > a fair bit of community involvement (RIR communities, IETF, and operational > forums such as NANOG and CaribNOG) in order to create the appropriate > incremental upgrades to the IRR. > > We are opening a new Community Consultation to solicit feedback on the ARIN > IRR Roadmap, detailed below. > > Please provide comments to arin-consult at arin.net. > > This consultation will remain open through 5:00 PM EST on Friday, 9 February > 2018. > > Regards, > > John Curran > President and CEO > American Registry for Internet Numbers (ARIN) > > *ARIN IRR Roadmap** > ** > **Background* > > In response to multiple ACSPs regarding IRR route validation (i.e. the > function whereby route objects are validated via the authorization of the > appropriate number resource holder), ARIN conducted an IRR community > consultation in April 2015. This consultation was opened because the issues > around IRR route validation are complex, and implementation was anticipated > to exceed the cost of most ACSP implementations. > Within the consultation, the ARIN community was asked three questions: > > * Should ARIN begin a new project to enable IRR route object validation > to the ARIN registry database? > * If yes, should this effort be coordinated with other RIRs to help > facilitate cross-registry authentication? > * If yes, should this effort also support third party IRR route object > authentication? > > There were eighteen individual participants in the consultation. Thirteen > were in favor of ARIN creating a more robust IRR, two were publicly against, > and three were unclear in their support or opposition. > > Nine participants expressed support for efforts to facilitate inter-RIR > authentication, and eight participants expressed support for 3rd party or > proxy registrations for authentication of route objects. > > Two participants suggested ARIN provide facilities for > authentication/authorization or delegation to IRRs not operated by an RIR. > Several participants had concerns regarding the implementation of an > ARIN-validated IRR. Three noted ARIN's past experience with the > implementation and cost of RPKI with respect to both community adoption and > opportunity-cost, and one participant expressed concerns for contractual > obligations that ARIN may place on resource holders provisioning information > in a validated IRR. > > *Implementation Experience Regarding ARIN's Current IRR* > > ARIN initially setup a RIPE-based IRR years ago. Over the years, we > upgraded it based on ACSP suggestions: IPv6 support was implemented in > December 2009, and PGP support with additional notifications was released in > September 2011. In both of these releases, we replicated the original > approach of using the RIPE database software system with loose coupling to > our mainline ARIN Online registry system. These upgrades did allow for > additional functionality, but it came at a very substantial cost of time and > unanticipated functionality issues related to the upgrades. > > When we undertook these upgrades, we chose to continue the separation in the > hopes of doing minimal environmental changes to ARIN's infrastructure to add > the suggested improvements. However, the RIPE codebase was not modularized, > with significant dependencies on RIPE environment, and consequently was not > ideal for use in ARIN's environment. One consequence was the repeated need > to pull down the latest release from RIPE, adjust the environment for their > software to work, make changes to it to allow functionality that we support, > remove out dependencies to resource checks that would not exist in our > system, and add dependency links to our system. This has been a very > labor-intensive process and it took a lot of engineering time to make the > system work. > > Adjusting to each upgrade from RIPE has also been challenging because of > innate differences our database structures. RIPE had two systems ? one being > a front-end database and the other being a back-end database with manual > synchronization between these two systems. At ARIN, we have just one system > that is placed behind the firewall and replicated out to the publically > available ARIN slaves as changes are made. The RIPE IRR codebase provided > for limited information to be shared to slaves via its replication schemes. > Given that ARIN's publically available interface is a slave, the output > available to our community was not the same as our internal master, and has > resulted in some confusion for ARIN IRR users. > > ARIN Registration Services Department also has challenges providing customer > support to IRR users. Common problems include: > > * Maintainers not being notified upon changes > * Cryptic responses to pgp-validation errors > * General lack of customer support features > > It was our hope that code re-use would save time and money. Unfortunately, > this was not the case, and the result was an awkward, difficult-to-operate, > and user-unfriendly system that requires considerable engineering time to > maintain. > It should also be noted that the IRR codebase in use by ARIN is no longer > supported or maintained by the RIPE NCC, as they have since completely > rewritten their IRR software. > > *Proposed Roadmap* > > Given the community feedback received in the consultation, and with due > regard to the past experience with reusing code for IRR software, ARIN staff > proposes a "ground-up" implementation of a validated IRR that will better > integrate with ARIN's current web portal, provisioning system, and other > registry functions. This path forward will be a multi-phased approach and > will rely on community?defined specifications and global RIR community > consensus. > > This approach will allow ARIN to field a routing registry incrementally, > providing utility to the community much sooner than a monolithic "big-bang" > release, and it will provide the community an opportunity to provide > feedback with respect to features and cost as the project progresses. > > * Produce a Simplified Profile of RPSL: Most of the complexity of RPSL > comes from routing registry features rarely used by the community. To reduce > the implementation costs around data modeling and parsing of complex RPSL > structures, ARIN will work with the operational community to identify the > most commonly used features of the language, and this subset will be > documented as an simplified RPSL profile to be used to guide development > efforts. > * Schedule Frequent Deployments: ARIN will adopt "continuous deployment" > strategies to allow for more frequent deployments, similar to the strategy > used today in development of the ARIN Online registry system. This will > allow the community to use new features of the IRR as they are developed. > > * Collaborate on Cross-RIR Authentication: ARIN will work with the other > RIRs engineering coordination activities to create an appropriate mechanism > for authentication and authorization of routing registry objects for which > the resources cross regional boundaries. > > * Provide an Easy IRR integration tool within ARIN Online: ARIN will > provide an simple tool within ARIN online for those users who wish to > explore the routing of their existing number resources and after successful > review, automatically update their corresponding IRR records to match > existing routing. > > * Migrate Data to the New IRR: Where possible, ARIN will create tools > and practices to help migrate data from the existing IRR to the new IRR > under the authority of resource holders in the ARIN registry. > > * Cooperate on Standards and Best Practices: Where applicable and > appropriate, ARIN will work with the IETF and the other RIRs on documenting > any resulting operational standards, profiles, and best practices. > > We do feel that this effort, once deployed, will help improve routing > coordination that exists on the Internet today. The proposed new ARIN IRR > will provide a clear and consistent path to allow ISPs to share their > routing policies. From markk at arin.net Wed Jan 10 16:22:05 2018 From: markk at arin.net (Mark Kosters) Date: Wed, 10 Jan 2018 21:22:05 +0000 Subject: [ARIN-consult] ACSP Consultation: ARIN Internet Routing Registry (IRR) Roadmap In-Reply-To: References: <762a5e1c-bf8a-d43a-531a-8b31276de92a@arin.net> Message-ID: <133FE5CB-7CD3-4C7E-9952-38B250EC7E3E@arin.net> On 1/9/18, 4:42 PM, "ARIN-consult on behalf of David R Huberman" wrote: In the Proposed Roadmap, there is a bullet point: > * Migrate Data to the New IRR: Where possible, ARIN will create tools > and practices to help migrate data from the existing IRR to the new IRR > under the authority of resource holders in the ARIN registry. I'm inferring from this that there will essentially be * irr.arin.net * new-irr.arin.net Both IRR directories will run for a period of time. Is that accurate? Or is the intention to populate the new IRR's data, stand it up, and similtaneously retire the existing IRR? Hi David Thanks for your questions. It is certainly a possibility to run both IRRs in parallel. I?m not so sure if that is the best idea as it may create confusion and/or additional workload. Regardless, one of the big questions underneath is how to do the migration of data from the old IRR to the new IRR. Should we start anew and ignore the existing IRR? If we are to try to migrate data, what kinds of validation should we do? And if we want to prep this a bit, what kind of analysis/reporting would the community like us to present to help guide us all to an answer? I?m not sure it is as simple as only move over old IRR objects to the new IRR when it matches what is seen in the routing system. We believe that in ARIN?s IRR there are a number of backup routes that are registered by vendors who provide services like DDOS protection. Thanks, Mark From daveid at panix.com Thu Jan 11 11:05:36 2018 From: daveid at panix.com (David R Huberman) Date: Thu, 11 Jan 2018 11:05:36 -0500 (EST) Subject: [ARIN-consult] ACSP Consultation: ARIN Internet Routing Registry (IRR) Roadmap In-Reply-To: <133FE5CB-7CD3-4C7E-9952-38B250EC7E3E@arin.net> References: <762a5e1c-bf8a-d43a-531a-8b31276de92a@arin.net> <133FE5CB-7CD3-4C7E-9952-38B250EC7E3E@arin.net> Message-ID: Hello, > It is certainly a possibility to run both IRRs in parallel. I'm not so > sure if that is the best idea as it may create confusion and/or > additional workload. > > Regardless, one of the big questions underneath is how to do the > migration of data from the old IRR to the new IRR. Should we start anew > and ignore the existing IRR? If we are to try to migrate data, what > kinds of validation should we do? And if we want to prep this a bit, > what kind of analysis/reporting would the community like us to present > to help guide us all to an answer? I?m not sure it is as simple as > only move over old IRR objects to the new IRR when it matches what is > seen in the routing system. We believe that in ARIN?s IRR there are a > number of backup routes that are registered by vendors who provide > services like DDOS protection. Ah ok. I misunderstood the Proposed Roadmap then, which is why I was asking for clarity. The issue is undecided, which makes sense to me. The correct answers will come in time, in consultation with all interested parties. Thank you, David From markk at arin.net Thu Jan 11 22:01:49 2018 From: markk at arin.net (Mark Kosters) Date: Fri, 12 Jan 2018 03:01:49 +0000 Subject: [ARIN-consult] ACSP Consultation: ARIN Internet Routing Registry (IRR) Roadmap In-Reply-To: <20180109215204.GM31128@vurt.meerval.net> References: <762a5e1c-bf8a-d43a-531a-8b31276de92a@arin.net> <20180109215204.GM31128@vurt.meerval.net> Message-ID: Hi Job Thanks for volunteering to help :^). We'd certainly like to hear your opinion on the plan. We are certainly open to any suggestions for improvements that you may have. This goes to anyone else on the list as well. Thanks, Mark On 1/9/18, 4:52 PM, "ARIN-consult on behalf of Job Snijders" wrote: >Dear ARIN, > >Where do I sign up to help? > >Kind regards, > >Job > >On Tue, Jan 09, 2018 at 04:27:58PM -0500, ARIN wrote: >> Over the last several years, ARIN has received multiple ARIN >>Consultation >> and Suggestion Process (ACSP) requests and fielded many customer >>suggestions >> about our existing Internet Routing Registry (IRR), and as a result, a >> community consultation was issued to gauge community interest for ARIN >>to >> take on the project of improving this service. The consensus response >>was >> that the community would like ARIN to: >> >> * Improve the validity of the IRR data >> * Work with the other RIR's on authorization schemes >> * Provide appropriate proxy registration services >> * Integrate/validate with the registration database >> >> To accomplish these goals, we anticipate that this work effort will >>involve >> a fair bit of community involvement (RIR communities, IETF, and >>operational >> forums such as NANOG and CaribNOG) in order to create the appropriate >> incremental upgrades to the IRR. >> >> We are opening a new Community Consultation to solicit feedback on the >>ARIN >> IRR Roadmap, detailed below. >> >> Please provide comments to arin-consult at arin.net. >> >> This consultation will remain open through 5:00 PM EST on Friday, 9 >>February >> 2018. >> >> Regards, >> >> John Curran >> President and CEO >> American Registry for Internet Numbers (ARIN) >> >> *ARIN IRR Roadmap** >> ** >> **Background* >> >> In response to multiple ACSPs regarding IRR route validation (i.e. the >> function whereby route objects are validated via the authorization of >>the >> appropriate number resource holder), ARIN conducted an IRR community >> consultation in April 2015. This consultation was opened because the >>issues >> around IRR route validation are complex, and implementation was >>anticipated >> to exceed the cost of most ACSP implementations. >> Within the consultation, the ARIN community was asked three questions: >> >> * Should ARIN begin a new project to enable IRR route object >>validation >> to the ARIN registry database? >> * If yes, should this effort be coordinated with other RIRs to help >> facilitate cross-registry authentication? >> * If yes, should this effort also support third party IRR route >>object >> authentication? >> >> There were eighteen individual participants in the consultation. >>Thirteen >> were in favor of ARIN creating a more robust IRR, two were publicly >>against, >> and three were unclear in their support or opposition. >> >> Nine participants expressed support for efforts to facilitate inter-RIR >> authentication, and eight participants expressed support for 3rd party >>or >> proxy registrations for authentication of route objects. >> >> Two participants suggested ARIN provide facilities for >> authentication/authorization or delegation to IRRs not operated by an >>RIR. >> Several participants had concerns regarding the implementation of an >> ARIN-validated IRR. Three noted ARIN's past experience with the >> implementation and cost of RPKI with respect to both community adoption >>and >> opportunity-cost, and one participant expressed concerns for contractual >> obligations that ARIN may place on resource holders provisioning >>information >> in a validated IRR. >> >> *Implementation Experience Regarding ARIN's Current IRR* >> >> ARIN initially setup a RIPE-based IRR years ago. Over the years, we >> upgraded it based on ACSP suggestions: IPv6 support was implemented in >> December 2009, and PGP support with additional notifications was >>released in >> September 2011. In both of these releases, we replicated the original >> approach of using the RIPE database software system with loose coupling >>to >> our mainline ARIN Online registry system. These upgrades did allow for >> additional functionality, but it came at a very substantial cost of >>time and >> unanticipated functionality issues related to the upgrades. >> >> When we undertook these upgrades, we chose to continue the separation >>in the >> hopes of doing minimal environmental changes to ARIN's infrastructure >>to add >> the suggested improvements. However, the RIPE codebase was not >>modularized, >> with significant dependencies on RIPE environment, and consequently was >>not >> ideal for use in ARIN's environment. One consequence was the repeated >>need >> to pull down the latest release from RIPE, adjust the environment for >>their >> software to work, make changes to it to allow functionality that we >>support, >> remove out dependencies to resource checks that would not exist in our >> system, and add dependency links to our system. This has been a very >> labor-intensive process and it took a lot of engineering time to make >>the >> system work. >> >> Adjusting to each upgrade from RIPE has also been challenging because of >> innate differences our database structures. RIPE had two systems ? one >>being >> a front-end database and the other being a back-end database with manual >> synchronization between these two systems. At ARIN, we have just one >>system >> that is placed behind the firewall and replicated out to the publically >> available ARIN slaves as changes are made. The RIPE IRR codebase >>provided >> for limited information to be shared to slaves via its replication >>schemes. >> Given that ARIN's publically available interface is a slave, the output >> available to our community was not the same as our internal master, and >>has >> resulted in some confusion for ARIN IRR users. >> >> ARIN Registration Services Department also has challenges providing >>customer >> support to IRR users. Common problems include: >> >> * Maintainers not being notified upon changes >> * Cryptic responses to pgp-validation errors >> * General lack of customer support features >> >> It was our hope that code re-use would save time and money. >>Unfortunately, >> this was not the case, and the result was an awkward, >>difficult-to-operate, >> and user-unfriendly system that requires considerable engineering time >>to >> maintain. >> It should also be noted that the IRR codebase in use by ARIN is no >>longer >> supported or maintained by the RIPE NCC, as they have since completely >> rewritten their IRR software. >> >> *Proposed Roadmap* >> >> Given the community feedback received in the consultation, and with due >> regard to the past experience with reusing code for IRR software, ARIN >>staff >> proposes a "ground-up" implementation of a validated IRR that will >>better >> integrate with ARIN's current web portal, provisioning system, and other >> registry functions. This path forward will be a multi-phased approach >>and >> will rely on community?defined specifications and global RIR community >> consensus. >> >> This approach will allow ARIN to field a routing registry incrementally, >> providing utility to the community much sooner than a monolithic >>"big-bang" >> release, and it will provide the community an opportunity to provide >> feedback with respect to features and cost as the project progresses. >> >> * Produce a Simplified Profile of RPSL: Most of the complexity of >>RPSL >> comes from routing registry features rarely used by the community. To >>reduce >> the implementation costs around data modeling and parsing of complex >>RPSL >> structures, ARIN will work with the operational community to identify >>the >> most commonly used features of the language, and this subset will be >> documented as an simplified RPSL profile to be used to guide development >> efforts. >> * Schedule Frequent Deployments: ARIN will adopt "continuous >>deployment" >> strategies to allow for more frequent deployments, similar to the >>strategy >> used today in development of the ARIN Online registry system. This will >> allow the community to use new features of the IRR as they are >>developed. >> >> * Collaborate on Cross-RIR Authentication: ARIN will work with the >>other >> RIRs engineering coordination activities to create an appropriate >>mechanism >> for authentication and authorization of routing registry objects for >>which >> the resources cross regional boundaries. >> >> * Provide an Easy IRR integration tool within ARIN Online: ARIN will >> provide an simple tool within ARIN online for those users who wish to >> explore the routing of their existing number resources and after >>successful >> review, automatically update their corresponding IRR records to match >> existing routing. >> >> * Migrate Data to the New IRR: Where possible, ARIN will create >>tools >> and practices to help migrate data from the existing IRR to the new IRR >> under the authority of resource holders in the ARIN registry. >> >> * Cooperate on Standards and Best Practices: Where applicable and >> appropriate, ARIN will work with the IETF and the other RIRs on >>documenting >> any resulting operational standards, profiles, and best practices. >> >> We do feel that this effort, once deployed, will help improve routing >> coordination that exists on the Internet today. The proposed new ARIN >>IRR >> will provide a clear and consistent path to allow ISPs to share their >> routing policies. >_______________________________________________ >ARIN-Consult >You are receiving this message because you are subscribed to the ARIN >Consult Mailing >List (ARIN-consult at arin.net). >Unsubscribe or manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/arin-consult Please contact the >ARIN Member Services >Help Desk at info at arin.net if you experience any issues. From jschiller at google.com Fri Jan 12 11:04:37 2018 From: jschiller at google.com (Jason Schiller) Date: Fri, 12 Jan 2018 11:04:37 -0500 Subject: [ARIN-consult] ACSP Consultation: ARIN Internet Routing Registry (IRR) Roadmap In-Reply-To: <762a5e1c-bf8a-d43a-531a-8b31276de92a@arin.net> References: <762a5e1c-bf8a-d43a-531a-8b31276de92a@arin.net> Message-ID: The road map for the ARIN IRR re-spin states: >> * Provide an Easy IRR integration tool within ARIN Online: ARIN will provide an simple tool within ARIN online for >> those users who wish to explore the routing of their existing number resources and after successful review, >> automatically update their corresponding IRR records to match existing routing. I have concerns that the text above suggests a less close coupling between WHOIS data and IRR data that I had hoped for. I think without a close coupling the work to reform the IRR becomes a lot less meaningful. Either my memory is faulty as to the extent the community wanted tight coupling with the WHOIS data, or the message was not clear enough. Either way I think it is worth while to get a clearer picture of what the community desires WRT close coupling of WHOIS and IRR data. This is not a simple question. There are a lot of different relationships, and there is a spectrum of the strength of the relationship between ARIN and the resource holder. For clarity I think it is best to initially scope our discussion to only the strongest ARIN - resource holder relationships, and decide about the level of coupling that makes sense, and then open the discussion up to some of the weaker relationships, and if we draw the line differently in those cases. For ARIN direct allocations, ARIN direct assignments,and ARIN assigned ASes, the relationship is strongest. ARIN knows the OrgID, ARIN has contact info, and ARIN interacts with the Organization at least once a year for payment. These resources can be managed by any ARIN Online account linked to the Org. Lets only consider these resources initially. 1. First, there is some overlapping data in ARIN WHOIS and ARIN IRR. It should be impossible for these to be out of sync. - If a resource's ARIN WHOIS information is updated, if there is IRR data it must also be updated. (see examples below ====) - If a resource is revoked / marked stale in WHOIS , the IRR (if it exists) must also be revoked / marked. 2. ARIN knows who can manage the resources of a given OrgID based on linked ARIN Online accounts and API keys those accounts have created. These same accounts / API Keys should be the ones that can manage IRR data either through ARIN online or a more traditional way that is tied back to the ARIN online account. (perhaps ARIN online accounts can be linked to maintainers managed in ARIN online) (might be useful for an ARIN online account to generate different API Keys, label them, and restrict access. e.g. the GFiber-SWIP key can SWIP /deSWIP anything in these ranges, and the bulk-whois key can download bulk whois, but nothing else.) - If a resource is transfered and that is reflected in the WHOIS, ownership of the IRR data must like wise be transfered. 3. When an IRR contains a relationship between two or more resources that have different owners is authorization from both required? (i think we have to sort this out a bit. Please Help) 3.a. Should a route holder be able to to designate an origin AS that they do not hold without the AS holder's acknowledgment? (maybe) 3.b. Should an AS holder be able to designate their AS as an origin for a route they do not hold with out the route holder's acknowledgement? (no. they can do all the work and just get the route holder to ack it though) 3.c. Should a route holder be able to remove an origin AS from their route without the AS holder's acknowledgment? (yes) 3.d. Should a route holder be able to adjust the routing policy associated with someone else's AS, but only with respect to their route without AS holders acknowledgment ? (no) 3.e. Should an AS holder be able to document a Peering relationship, transit customer relationship, or transit provider relationship with another AS without that AS holder's approval? (maybe yes) 4. If we include routes where the strength of the relationship between ARIN and the resource holder is weaker, then I suggest we clearly mark them. - Think there is a big spectrum here and we should table this discussion until we sort out the clear case first. In short to what extent do we think ARIN's IRR data should leverage (where it exists) the unique relationship ARIN has between it and the resource holders? ___Jason ============= this should not be possible: whois -h rr.arin.net as19527 % Information related to 'AS19527' aut-num: AS19527 as-name: MEEBO descr: Meebo, Inc. admin-c: CKO60-ARIN tech-c: CKO60-ARIN mnt-by: MNT-MEEBO source: ARIN # Filtered whois -h whois.arin.net 19527 # # The following results may also be obtained via: # https://whois.arin.net/rest/asns;q=19527?showDetails=true&ext=netref2 # ASNumber: 19527 ASName: GOOGLE-2 ASHandle: AS19527 RegDate: 2007-08-17 Updated: 2018-01-10 Ref: https://whois.arin.net/rest/asn/AS19527 OrgName: Google LLC OrgId: GOOGL-2 Address: 1600 Amphitheatre Parkway City: Mountain View StateProv: CA PostalCode: 94043 Country: US RegDate: 2006-09-29 Updated: 2017-12-21 Ref: https://whois.arin.net/rest/org/GOOGL-2 OrgNOCHandle: GCABU-ARIN OrgNOCName: GC Abuse OrgNOCPhone: +1-650-253-0000 OrgNOCEmail: google-cloud-compliance at google.com OrgNOCRef: https://whois.arin.net/rest/poc/GCABU-ARIN OrgAbuseHandle: GCABU-ARIN OrgAbuseName: GC Abuse OrgAbusePhone: +1-650-253-0000 OrgAbuseEmail: google-cloud-compliance at google.com OrgAbuseRef: https://whois.arin.net/rest/poc/GCABU-ARIN OrgTechHandle: ZG39-ARIN OrgTechName: Google LLC OrgTechPhone: +1-650-253-0000 OrgTechEmail: arin-contact at google.com OrgTechRef: https://whois.arin.net/rest/poc/ZG39-ARIN whois -h rr.arin.net "74.114.24.0/21" % Information related to '74.114.24.0/21AS19527' route: 74.114.24.0/21 descr: meebo-east origin: AS19527 mnt-by: MNT-MEEBO source: ARIN # Filtered whois -h whois.arin.net 74.114.24.0 # # The following results may also be obtained via: # https://whois.arin.net/rest/nets;q=74.114.24.0?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2 # NetRange: 74.114.24.0 - 74.114.31.255 CIDR: 74.114.24.0/21 NetName: GOOGLE NetHandle: NET-74-114-24-0-1 Parent: NET74 (NET-74-0-0-0-0) NetType: Direct Allocation OriginAS: AS15169 Organization: Google LLC (GOGL) RegDate: 2009-05-21 Updated: 2018-01-12 Ref: https://whois.arin.net/rest/net/NET-74-114-24-0-1 OrgName: Google LLC OrgId: GOGL Address: 1600 Amphitheatre Parkway City: Mountain View StateProv: CA PostalCode: 94043 Country: US RegDate: 2000-03-30 Updated: 2017-12-21 Ref: https://whois.arin.net/rest/org/GOGL OrgAbuseHandle: ABUSE5250-ARIN OrgAbuseName: Abuse OrgAbusePhone: +1-650-253-0000 OrgAbuseEmail: network-abuse at google.com OrgAbuseRef: https://whois.arin.net/rest/poc/ABUSE5250-ARIN OrgTechHandle: ZG39-ARIN OrgTechName: Google LLC OrgTechPhone: +1-650-253-0000 OrgTechEmail: arin-contact at google.com OrgTechRef: https://whois.arin.net/rest/poc/ZG39-ARIN On Tue, Jan 9, 2018 at 4:27 PM, ARIN wrote: > Over the last several years, ARIN has received multiple ARIN Consultation > and Suggestion Process (ACSP) requests and fielded many customer > suggestions about our existing Internet Routing Registry (IRR), and as a > result, a community consultation was issued to gauge community interest for > ARIN to take on the project of improving this service. The consensus > response was that the community would like ARIN to: > > * Improve the validity of the IRR data > * Work with the other RIR's on authorization schemes > * Provide appropriate proxy registration services > * Integrate/validate with the registration database > > To accomplish these goals, we anticipate that this work effort will > involve a fair bit of community involvement (RIR communities, IETF, and > operational forums such as NANOG and CaribNOG) in order to create the > appropriate incremental upgrades to the IRR. > > We are opening a new Community Consultation to solicit feedback on the > ARIN IRR Roadmap, detailed below. > > Please provide comments to arin-consult at arin.net. > > This consultation will remain open through 5:00 PM EST on Friday, 9 > February 2018. > > Regards, > > John Curran > President and CEO > American Registry for Internet Numbers (ARIN) > > *ARIN IRR Roadmap* > > *Background* > > In response to multiple ACSPs regarding IRR route validation (i.e. the > function whereby route objects are validated via the authorization of the > appropriate number resource holder), ARIN conducted an IRR community > consultation in April 2015. This consultation was opened because the issues > around IRR route validation are complex, and implementation was anticipated > to exceed the cost of most ACSP implementations. > Within the consultation, the ARIN community was asked three questions: > > * Should ARIN begin a new project to enable IRR route object > validation to the ARIN registry database? > * If yes, should this effort be coordinated with other RIRs to help > facilitate cross-registry authentication? > * If yes, should this effort also support third party IRR route object > authentication? > > There were eighteen individual participants in the consultation. Thirteen > were in favor of ARIN creating a more robust IRR, two were publicly > against, and three were unclear in their support or opposition. > > Nine participants expressed support for efforts to facilitate inter-RIR > authentication, and eight participants expressed support for 3rd party or > proxy registrations for authentication of route objects. > > Two participants suggested ARIN provide facilities for > authentication/authorization or delegation to IRRs not operated by an RIR. > Several participants had concerns regarding the implementation of an > ARIN-validated IRR. Three noted ARIN's past experience with the > implementation and cost of RPKI with respect to both community adoption and > opportunity-cost, and one participant expressed concerns for contractual > obligations that ARIN may place on resource holders provisioning > information in a validated IRR. > > *Implementation Experience Regarding ARIN's Current IRR* > > ARIN initially setup a RIPE-based IRR years ago. Over the years, we > upgraded it based on ACSP suggestions: IPv6 support was implemented in > December 2009, and PGP support with additional notifications was released > in September 2011. In both of these releases, we replicated the original > approach of using the RIPE database software system with loose coupling to > our mainline ARIN Online registry system. These upgrades did allow for > additional functionality, but it came at a very substantial cost of time > and unanticipated functionality issues related to the upgrades. > > When we undertook these upgrades, we chose to continue the separation in > the hopes of doing minimal environmental changes to ARIN's infrastructure > to add the suggested improvements. However, the RIPE codebase was not > modularized, with significant dependencies on RIPE environment, and > consequently was not ideal for use in ARIN's environment. One consequence > was the repeated need to pull down the latest release from RIPE, adjust the > environment for their software to work, make changes to it to allow > functionality that we support, remove out dependencies to resource checks > that would not exist in our system, and add dependency links to our system. > This has been a very labor-intensive process and it took a lot of > engineering time to make the system work. > > Adjusting to each upgrade from RIPE has also been challenging because of > innate differences our database structures. RIPE had two systems ? one > being a front-end database and the other being a back-end database with > manual synchronization between these two systems. At ARIN, we have just one > system that is placed behind the firewall and replicated out to the > publically available ARIN slaves as changes are made. The RIPE IRR codebase > provided for limited information to be shared to slaves via its replication > schemes. Given that ARIN's publically available interface is a slave, the > output available to our community was not the same as our internal master, > and has resulted in some confusion for ARIN IRR users. > > ARIN Registration Services Department also has challenges providing > customer support to IRR users. Common problems include: > > * Maintainers not being notified upon changes > * Cryptic responses to pgp-validation errors > * General lack of customer support features > > It was our hope that code re-use would save time and money. Unfortunately, > this was not the case, and the result was an awkward, difficult-to-operate, > and user-unfriendly system that requires considerable engineering time to > maintain. > It should also be noted that the IRR codebase in use by ARIN is no longer > supported or maintained by the RIPE NCC, as they have since completely > rewritten their IRR software. > > *Proposed Roadmap* > > Given the community feedback received in the consultation, and with due > regard to the past experience with reusing code for IRR software, ARIN > staff proposes a "ground-up" implementation of a validated IRR that will > better integrate with ARIN's current web portal, provisioning system, and > other registry functions. This path forward will be a multi-phased approach > and will rely on community?defined specifications and global RIR community > consensus. > > This approach will allow ARIN to field a routing registry incrementally, > providing utility to the community much sooner than a monolithic "big-bang" > release, and it will provide the community an opportunity to provide > feedback with respect to features and cost as the project progresses. > > * Produce a Simplified Profile of RPSL: Most of the complexity of RPSL > comes from routing registry features rarely used by the community. To > reduce the implementation costs around data modeling and parsing of complex > RPSL structures, ARIN will work with the operational community to identify > the most commonly used features of the language, and this subset will be > documented as an simplified RPSL profile to be used to guide development > efforts. > * Schedule Frequent Deployments: ARIN will adopt "continuous > deployment" strategies to allow for more frequent deployments, similar to > the strategy used today in development of the ARIN Online registry system. > This will allow the community to use new features of the IRR as they are > developed. > > * Collaborate on Cross-RIR Authentication: ARIN will work with the > other RIRs engineering coordination activities to create an appropriate > mechanism for authentication and authorization of routing registry objects > for which the resources cross regional boundaries. > > * Provide an Easy IRR integration tool within ARIN Online: ARIN will > provide an simple tool within ARIN online for those users who wish to > explore the routing of their existing number resources and after successful > review, automatically update their corresponding IRR records to match > existing routing. > > * Migrate Data to the New IRR: Where possible, ARIN will create tools > and practices to help migrate data from the existing IRR to the new IRR > under the authority of resource holders in the ARIN registry. > > * Cooperate on Standards and Best Practices: Where applicable and > appropriate, ARIN will work with the IETF and the other RIRs on documenting > any resulting operational standards, profiles, and best practices. > > We do feel that this effort, once deployed, will help improve routing > coordination that exists on the Internet today. The proposed new ARIN IRR > will provide a clear and consistent path to allow ISPs to share their > routing policies. > > > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN > Consult Mailing > List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-consult Please contact the > ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From daveid at panix.com Fri Jan 12 11:52:41 2018 From: daveid at panix.com (David R Huberman) Date: Fri, 12 Jan 2018 11:52:41 -0500 (EST) Subject: [ARIN-consult] ACSP Consultation: ARIN Internet Routing Registry (IRR) Roadmap In-Reply-To: References: <762a5e1c-bf8a-d43a-531a-8b31276de92a@arin.net> Message-ID: > I have concerns that the text above suggests a less close coupling > between WHOIS data and IRR data that I had hoped for. I think without a > close coupling the work to reform the IRR becomes a lot less meaningful. I strongly agree. The first level of abstraction is the start_ip and end_ip of inetnum objects. Rules I think must exist: - inetnum objects must exactly match a NET object in ARIN Whois - inet6num objects must exactly match a NET object in ARIN Whois No inetnum or inet6num object may be asserted in ARIN IRR if it does not already exist in ARIN Whois. Why? Because this is how "bad actors" have abused RIPEdb and other wide open IRRs to perform one critical function of setting up a malevolent operation. RIPE's db-wg has been having this discussion, and there is very clear consensus on the rules I propose above The second level of abstraction is authorization. As Jason writes: > For ARIN direct allocations, ARIN direct assignments,and ARIN assigned > ASes, the relationship is strongest. ARIN knows the OrgID, ARIN has > contact info, and ARIN interacts with the Organization at least once a > year for payment. These resources can be managed by any ARIN Online > account linked to the Org. A rule that I think would make sense: - maintainer objects are always authorized by the ORG objects in Whois. This is obvious. What is less obvious is that you want to authorize scripting to ADD/UPDATE/DELETE objects under your maintainer. So something like: - While authorized contacts can add NIC handles to maintainers, notifications (notify:) for the maintainer object must always be sent to the current ORG pocs to ensure they are aware of changes. Now Jason brings up data integrity > 1. First, there is some overlapping data in ARIN WHOIS and ARIN IRR. > It should be impossible for these to be out of sync. Agreed. > - If a resource's ARIN WHOIS information is updated, if there is IRR data > it must also be updated. Agreed. But with forewarning. > - If a resource is revoked / marked stale in WHOIS , the IRR (if it > exists) must also be revoked / marked. Absolutely, and obvious to everyone I hope. > 2. ARIN knows who can manage the resources of a given OrgID based on > linked ARIN Online accounts and API keys those accounts have created. > These same accounts / API Keys should be the ones that can manage IRR > data either through ARIN online or a more traditional way that is tied > back to the ARIN online account. Gotta speak up here for "more traditional". Every operator I've ever been at still does this the old and reliable way: email, with cryto signatures. At scale, it makes sense to have an API for all this, and leverage the API KEY infrastructure already in ARIN Whois. But for discrete changes (which affect the majority of IRR users), email needs to remain an option, in my opinion. > - If a resource is transfered and that is reflected in the WHOIS, > ownership of the IRR data must like wise be transfered. Ding ding ding! Nice thinking, Jason. > 3. When an IRR contains a relationship between two or more resources > that have different owners is authorization from both required? (i think > we have to sort this out a bit. Please Help) No. There is no need for IRR to worry about multiple parties. Just like SWIP, if authorization exists, authorization exists. > 3.a. Should a route holder be able to to designate an origin AS that > they do not hold without the AS holder's acknowledgment? (maybe) The autnum and related objects need some real discussion here. Like Jason, I suspect the answer is maybe, but I don't know enough to know. I can rope in experts into this thread if you need us to. > 3.b. Should an AS holder be able to designate their AS as an origin for > a route they > do not hold with out the route holder's acknowledgement? > (no. they can do all the work and just get the route holder to ack > it though) Disagree here, because if the route object is valid, the IRR doesn't need to authorize the AS relationship. But that's all part of "the autnum and related objects need some real discussion here". > 3.c. Should a route holder be able to remove an origin AS from their > route without the AS holder's acknowledgment? (yes) Yes > > 3.d. Should a route holder be able to adjust the routing policy > associated with someone else's AS, but only with respect to their route without AS > holders acknowledgment ? (no) Didn't grok the situation you're describing. > 3.e. Should an AS holder be able to document a Peering relationship, > transit customer relationship, or transit provider relationship with another > AS without that AS holder's approval? (maybe yes) Yes but same as above. David From jayb at braeburn.org Fri Jan 12 17:04:57 2018 From: jayb at braeburn.org (Jay Borkenhagen) Date: Fri, 12 Jan 2018 17:04:57 -0500 Subject: [ARIN-consult] ACSP Consultation: ARIN Internet Routing Registry (IRR) Roadmap In-Reply-To: References: <762a5e1c-bf8a-d43a-531a-8b31276de92a@arin.net> <20180109215204.GM31128@vurt.meerval.net> Message-ID: <23129.12553.829938.810069@oz.mt.att.com> Hi Mark, Sign me up, too. What are your thoughts for how to make timely progress? I am very happy this consultation came up again this week so don't take this the wrong way, but the previous consultation on the IRR topic was almost 3 years ago. I hope that in the coming 3 years (or less) some real, tangible improvements will have been made. Thanks. Jay B. Mark Kosters writes: > Hi Job > > Thanks for volunteering to help :^). We'd certainly like to hear your > opinion on the plan. We are certainly open to any suggestions for > improvements that you may have. This goes to anyone else on the list as > well. > > Thanks, > Mark > > On 1/9/18, 4:52 PM, "ARIN-consult on behalf of Job Snijders" > wrote: > > >Dear ARIN, > > > >Where do I sign up to help? > > > >Kind regards, > > > >Job > > From jcurran at arin.net Fri Jan 12 17:47:55 2018 From: jcurran at arin.net (John Curran) Date: Fri, 12 Jan 2018 22:47:55 +0000 Subject: [ARIN-consult] ACSP Consultation: ARIN Internet Routing Registry (IRR) Roadmap In-Reply-To: <23129.12553.829938.810069@oz.mt.att.com> References: <762a5e1c-bf8a-d43a-531a-8b31276de92a@arin.net> <20180109215204.GM31128@vurt.meerval.net> <23129.12553.829938.810069@oz.mt.att.com> Message-ID: On 12 Jan 2018, at 2:04 PM, Jay Borkenhagen wrote: > > Hi Mark, > > Sign me up, too. > > What are your thoughts for how to make timely progress? I am very > happy this consultation came up again this week so don't take this the > wrong way, but the previous consultation on the IRR topic was almost 3 > years ago. I hope that in the coming 3 years (or less) some real, > tangible improvements will have been made. Jay - Yes - we did spent quite a bit of time two years back confirming whether the community wanted us to do any work at all in the IRR area. We then circulated the draft through the ARIN Services WG (but it had to follow the CKN-23 work item already underway.) We are committed to conducting this consultation promptly in the first few months of 2018, and starting the IRR development work immediately thereafter. Thanks for asking! /John John Curran President and CEO ARIN From rfg at tristatelogic.com Fri Jan 12 18:10:38 2018 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 12 Jan 2018 15:10:38 -0800 Subject: [ARIN-consult] ACSP Consultation: ARIN Internet Routing Registry (IRR) Roadmap Message-ID: <37781.1515798638@segfault.tristatelogic.com> An acquaintance of mine just called my attention to this thread, due to the possible relevance of some comments I just made the other day to a couple of the RIPE mailing lists. I don't think that I have terribly much to add, but I did just want to make two quick points. Firstly, having read the message from John Curran that began this thread, I just wanted to compliment John for that very clear, detailed and workman-like product. It is certainly nice for someone, such as myself, who hasn't been following these issues to be able to read a good capsule summary of the current state of play, and its historical genesis. Second, I just wanted to highlight this one bullet point that John already has in the RoadMap: * Collaborate on Cross-RIR Authentication: ARIN will work with the other RIRs engineering coordination activities to create an appropriate mechanism for authentication and authorization of routing registry objects for which the resources cross regional boundaries. For whetever it's worth, I'd just like to add my two cents by saying that my hope is that this goal/task will be expedited to the maximum extent possible. Although I'm a firm and ardent believer in democratic processes, I am far from the first to observe that such processes are often both messy and slow. For that reason, and despite my strong democratic leanings, in this specific case I personally would like nothing better than to see all of the heads of the Five Families meet, perhaps in wood paneled conference room in New York, and simply agree to "make it happen", i.e. to set up some sort of routine automated exchange of data so that any RIR could easily know if party `X' is or is not, at the very least, a registered dues-paying member of at least one RIR somewhere on planet Earth. Regards, rfg From jschiller at google.com Tue Jan 16 13:21:16 2018 From: jschiller at google.com (Jason Schiller) Date: Tue, 16 Jan 2018 13:21:16 -0500 Subject: [ARIN-consult] ACSP Consultation: ARIN Internet Routing Registry (IRR) Roadmap In-Reply-To: References: <762a5e1c-bf8a-d43a-531a-8b31276de92a@arin.net> Message-ID: Sounds to me like David and I are in agreement, WRT a close coupling between ARIN WHOIS and ARIN IRR, and the autnum and related objects need some real discussion here. Before plunging into that I think it is worth while and solicit what other's opinions are WRT a tight coupling between the ARIN IRR and ARIN WHOIS at least for ARIN direct allocations, ARIN direct assignments, ARIN issued ASNs. Looks like Tony is supportive of this approach. Can others take a moment to comment on this particular question? __Jason On Fri, Jan 12, 2018 at 11:52 AM, David R Huberman wrote: > I have concerns that the text above suggests a less close coupling between >> WHOIS data and IRR data that I had hoped for. I think without a close >> coupling the work to reform the IRR becomes a lot less meaningful. >> > > I strongly agree. > > The first level of abstraction is the start_ip and end_ip of inetnum > objects. Rules I think must exist: > > - inetnum objects must exactly match a NET object in ARIN Whois > - inet6num objects must exactly match a NET object in ARIN Whois > > No inetnum or inet6num object may be asserted in ARIN IRR if it does not > already exist in ARIN Whois. Why? Because this is how "bad actors" have > abused RIPEdb and other wide open IRRs to perform one critical function of > setting up a malevolent operation. > > RIPE's db-wg has been having this discussion, and there is very clear > consensus on the rules I propose above > > The second level of abstraction is authorization. As Jason writes: > > For ARIN direct allocations, ARIN direct assignments,and ARIN assigned >> ASes, the relationship is strongest. ARIN knows the OrgID, ARIN has contact >> info, and ARIN interacts with the Organization at least once a year for >> payment. These resources can be managed by any ARIN Online account linked >> to the Org. >> > > A rule that I think would make sense: > > - maintainer objects are always authorized by the ORG objects in Whois. > > This is obvious. What is less obvious is that you want to authorize > scripting to ADD/UPDATE/DELETE objects under your maintainer. So something > like: > > - While authorized contacts can add NIC handles to maintainers, > notifications (notify:) for the maintainer object must always be sent to > the current ORG pocs to ensure they are aware of changes. > > Now Jason brings up data integrity > > 1. First, there is some overlapping data in ARIN WHOIS and ARIN IRR. It >> should be impossible for these to be out of sync. >> > > Agreed. > > - If a resource's ARIN WHOIS information is updated, if there is IRR data >> it must also be updated. >> > > Agreed. But with forewarning. > > - If a resource is revoked / marked stale in WHOIS , the IRR (if it >> exists) must also be revoked / marked. >> > > Absolutely, and obvious to everyone I hope. > > 2. ARIN knows who can manage the resources of a given OrgID based on >> linked ARIN Online accounts and API keys those accounts have created. These >> same accounts / API Keys should be the ones that can manage IRR data either >> through ARIN online or a more traditional way that is tied back to the ARIN >> online account. >> > > Gotta speak up here for "more traditional". Every operator I've ever been > at still does this the old and reliable way: email, with cryto > signatures. At scale, it makes sense to have an API for all this, and > leverage the API KEY infrastructure already in ARIN Whois. But for > discrete changes (which affect the majority of IRR users), email needs to > remain an option, in my opinion. > > - If a resource is transfered and that is reflected in the WHOIS, >> ownership of the IRR data must like wise be transfered. >> > > Ding ding ding! Nice thinking, Jason. > > 3. When an IRR contains a relationship between two or more resources that >> have different owners is authorization from both required? (i think we have >> to sort this out a bit. Please Help) >> > > No. There is no need for IRR to worry about multiple parties. Just like > SWIP, if authorization exists, authorization exists. > > 3.a. Should a route holder be able to to designate an origin AS that they >> do not hold without the AS holder's acknowledgment? (maybe) >> > > The autnum and related objects need some real discussion here. Like Jason, > I suspect the answer is maybe, but I don't know enough to know. I can rope > in experts into this thread if you need us to. > > 3.b. Should an AS holder be able to designate their AS as an origin for a >> route they >> do not hold with out the route holder's acknowledgement? >> (no. they can do all the work and just get the route holder to ack >> it though) >> > > Disagree here, because if the route object is valid, the IRR doesn't need > to authorize the AS relationship. But that's all part of "the autnum and > related objects need some real discussion here". > > 3.c. Should a route holder be able to remove an origin AS from their route >> without the AS holder's acknowledgment? (yes) >> > > Yes > > >> 3.d. Should a route holder be able to adjust the routing policy >> associated with someone else's AS, but only with respect to their route >> without AS >> holders acknowledgment ? (no) >> > > Didn't grok the situation you're describing. > > 3.e. Should an AS holder be able to document a Peering relationship, >> transit customer relationship, or transit provider relationship with another >> AS without that AS holder's approval? (maybe yes) >> > > Yes but same as above. > > David > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayb at braeburn.org Wed Jan 17 14:24:20 2018 From: jayb at braeburn.org (Jay Borkenhagen) Date: Wed, 17 Jan 2018 14:24:20 -0500 Subject: [ARIN-consult] ACSP Consultation: ARIN Internet Routing Registry (IRR) Roadmap In-Reply-To: References: <762a5e1c-bf8a-d43a-531a-8b31276de92a@arin.net> Message-ID: <23135.41700.255674.336289@oz.mt.att.com> The primary goal of this effort should be to utilize ARIN's unique position in the Internet number resource management system to produce the most reliable and most accurate IRR for ARIN-assigned resources. "Tight coupling between ARIN WHOIS and ARIN IRR" seems like a nice, concise wording for this concept, and I am 100% in favor of it. Does anyone believe that "Tight coupling between ARIN WHOIS and ARIN IRR" is *not* the primary goal of the current exercise? If so, please speak up. Thanks. Jay B. On 16-Jan-2018, Jason Schiller writes: > Sounds to me like David and I are in agreement, WRT a close > coupling between ARIN WHOIS and ARIN IRR, and the autnum > and related objects need some real discussion here. > > Before plunging into that I think it is worth while and solicit what > other's opinions > are WRT a tight coupling between the ARIN IRR and ARIN WHOIS at least for > ARIN direct allocations, ARIN direct assignments, ARIN issued ASNs. > > Looks like Tony is supportive of this approach. > > Can others take a moment to comment on this particular question? > > __Jason > > On Fri, Jan 12, 2018 at 11:52 AM, David R Huberman wrote: > > > I have concerns that the text above suggests a less close coupling between > >> WHOIS data and IRR data that I had hoped for. I think without a close > >> coupling the work to reform the IRR becomes a lot less meaningful. > >> > > > > I strongly agree. > > > > The first level of abstraction is the start_ip and end_ip of inetnum > > objects. Rules I think must exist: > > > > - inetnum objects must exactly match a NET object in ARIN Whois > > - inet6num objects must exactly match a NET object in ARIN Whois > > > > No inetnum or inet6num object may be asserted in ARIN IRR if it does not > > already exist in ARIN Whois. Why? Because this is how "bad actors" have > > abused RIPEdb and other wide open IRRs to perform one critical function of > > setting up a malevolent operation. > > > > RIPE's db-wg has been having this discussion, and there is very clear > > consensus on the rules I propose above > > > > The second level of abstraction is authorization. As Jason writes: > > > > For ARIN direct allocations, ARIN direct assignments,and ARIN assigned > >> ASes, the relationship is strongest. ARIN knows the OrgID, ARIN has contact > >> info, and ARIN interacts with the Organization at least once a year for > >> payment. These resources can be managed by any ARIN Online account linked > >> to the Org. > >> > > > > A rule that I think would make sense: > > > > - maintainer objects are always authorized by the ORG objects in Whois. > > > > This is obvious. What is less obvious is that you want to authorize > > scripting to ADD/UPDATE/DELETE objects under your maintainer. So something > > like: > > > > - While authorized contacts can add NIC handles to maintainers, > > notifications (notify:) for the maintainer object must always be sent to > > the current ORG pocs to ensure they are aware of changes. > > > > Now Jason brings up data integrity > > > > 1. First, there is some overlapping data in ARIN WHOIS and ARIN IRR. It > >> should be impossible for these to be out of sync. > >> > > > > Agreed. > > > > - If a resource's ARIN WHOIS information is updated, if there is IRR data > >> it must also be updated. > >> > > > > Agreed. But with forewarning. > > > > - If a resource is revoked / marked stale in WHOIS , the IRR (if it > >> exists) must also be revoked / marked. > >> > > > > Absolutely, and obvious to everyone I hope. > > > > 2. ARIN knows who can manage the resources of a given OrgID based on > >> linked ARIN Online accounts and API keys those accounts have created. These > >> same accounts / API Keys should be the ones that can manage IRR data either > >> through ARIN online or a more traditional way that is tied back to the ARIN > >> online account. > >> > > > > Gotta speak up here for "more traditional". Every operator I've ever been > > at still does this the old and reliable way: email, with cryto > > signatures. At scale, it makes sense to have an API for all this, and > > leverage the API KEY infrastructure already in ARIN Whois. But for > > discrete changes (which affect the majority of IRR users), email needs to > > remain an option, in my opinion. > > > > - If a resource is transfered and that is reflected in the WHOIS, > >> ownership of the IRR data must like wise be transfered. > >> > > > > Ding ding ding! Nice thinking, Jason. > > > > 3. When an IRR contains a relationship between two or more resources that > >> have different owners is authorization from both required? (i think we have > >> to sort this out a bit. Please Help) > >> > > > > No. There is no need for IRR to worry about multiple parties. Just like > > SWIP, if authorization exists, authorization exists. > > > > 3.a. Should a route holder be able to to designate an origin AS that they > >> do not hold without the AS holder's acknowledgment? (maybe) > >> > > > > The autnum and related objects need some real discussion here. Like Jason, > > I suspect the answer is maybe, but I don't know enough to know. I can rope > > in experts into this thread if you need us to. > > > > 3.b. Should an AS holder be able to designate their AS as an origin for a > >> route they > >> do not hold with out the route holder's acknowledgement? > >> (no. they can do all the work and just get the route holder to ack > >> it though) > >> > > > > Disagree here, because if the route object is valid, the IRR doesn't need > > to authorize the AS relationship. But that's all part of "the autnum and > > related objects need some real discussion here". > > > > 3.c. Should a route holder be able to remove an origin AS from their route > >> without the AS holder's acknowledgment? (yes) > >> > > > > Yes > > > > > >> 3.d. Should a route holder be able to adjust the routing policy > >> associated with someone else's AS, but only with respect to their route > >> without AS > >> holders acknowledgment ? (no) > >> > > > > Didn't grok the situation you're describing. > > > > 3.e. Should an AS holder be able to document a Peering relationship, > >> transit customer relationship, or transit provider relationship with another > >> AS without that AS holder's approval? (maybe yes) > >> > > > > Yes but same as above. > > > > David > > > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN Consult Mailing > List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. From job at ntt.net Wed Jan 17 14:37:09 2018 From: job at ntt.net (Job Snijders) Date: Wed, 17 Jan 2018 19:37:09 +0000 Subject: [ARIN-consult] ACSP Consultation: ARIN Internet Routing Registry (IRR) Roadmap In-Reply-To: References: <762a5e1c-bf8a-d43a-531a-8b31276de92a@arin.net> Message-ID: <20180117193709.GW68483@vurt.meerval.net> On Tue, Jan 16, 2018 at 01:21:16PM -0500, Jason Schiller wrote: > Sounds to me like David and I are in agreement, WRT a close coupling > between ARIN WHOIS and ARIN IRR, and the autnum and related objects > need some real discussion here. > > Before plunging into that I think it is worth while and solicit what > other's opinions are WRT a tight coupling between the ARIN IRR and > ARIN WHOIS at least for ARIN direct allocations, ARIN direct > assignments, ARIN issued ASNs. Yes, agreed, that is a critical requirement to ensure that new IRR work can assert a degree of authority, so people can trust the data. The current ARIN IRR did not meet my expectations in that regard. A note on non-ARIN resources in the new ARIN IRR framework, I can share experience from the RIPE and APNIC region in that regard. In the RIPE region non-RIPE objects were also allowed in the RIPE IRR. This has led to much abuse and lack of clarity on the authoritative status of objects. The RIPE Database WG has spend years trying to come to a consensus on how to fix this. If I had been there at the time when RIPE IRR originally started, I would've made sure that non-RIPE could not exist in the RIPE IRR, it would've saved us tons of trouble. APNIC got it right from day #1. In APNIC IRR only APNIC-managed space can exist. Both RIRs have made provisions to accomodate resources that are transferring in or out. Kind regards, Job From Tony_Tauber at comcast.com Mon Jan 22 15:21:16 2018 From: Tony_Tauber at comcast.com (Tauber, Tony) Date: Mon, 22 Jan 2018 20:21:16 +0000 Subject: [ARIN-consult] ACSP Consultation: ARIN Internet Routing Registry (IRR) Roadmap In-Reply-To: References: <762a5e1c-bf8a-d43a-531a-8b31276de92a@arin.net> Message-ID: Forwarding to the list as there was some problem last week when I sent it first, though the cc?d folks received it. Thanks, Tony From: Tony Tauber Date: Tuesday, January 16, 2018 at 11:47 AM To: David R Huberman , Jason Schiller Cc: Jared Mauch , "" Subject: Re: [ARIN-consult] ACSP Consultation: ARIN Internet Routing Registry (IRR) Roadmap Mark, John, et. al., Count me in (like Job and Jay) to help. In my mind, and there are likely many wrinkles and cases I?m not thinking of, it goes something like this: At least for resources it?s assigned directly, ARIN already has the data to pro-actively publish plausible AS origin data based on OrgID. Their XML REST API already brings these things together. For instance, the OrgID record for MIT shows ?Related Networks? and ?Related ASNs?. How about if ARIN would publish in IRR/RPSL format route and route6 objects which link each related network with each related AS as a plausible origin? It would create more records that absolutely necessary, but it seems all would be ?possible? and could be done proactively so as to not require explicit action on everyone?s part. ARIN online could be used to manage records beyond that. Personally, I don?t know that the ?email method? needs to be maintained and is really archaic by most measures. Asking new personnel to create plain-text emails and make sure there are no invisible characters and line termination just so is really a bit much to ask these days. Don?t get me started on management of shared passwords that aren?t bound to any specific individual(s). If there?s a need for bulk/automated operation, APIs with key or other modern authentication approaches should be used. I don?t know enough about details of ARIN to predict how legacy assignments would be treated. The existing ARIN IRR data should be decommissioned at some point where data can?t be aligned with the new methods. I would like to see other RIRs follow suit and hammer out any necessary interworking. I?m not sure what the usefulness of non-RIR IRR repositories would then be (i.e., ones with weaker/no authorization models), but that?s not for ARIN to decide. I?m sure there may be a host of things I?m not considering but that?s my idea of how things could/would work sanely that would provide improved confidence for all. Tony -----Original Message----- From: ARIN-consult on behalf of David R Huberman Date: Friday, January 12, 2018 at 11:52 AM To: Jason Schiller Cc: Jared Mauch , "" Subject: Re: [ARIN-consult] ACSP Consultation: ARIN Internet Routing Registry (IRR) Roadmap > I have concerns that the text above suggests a less close coupling > between WHOIS data and IRR data that I had hoped for. I think without a > close coupling the work to reform the IRR becomes a lot less meaningful. I strongly agree. The first level of abstraction is the start_ip and end_ip of inetnum objects. Rules I think must exist: - inetnum objects must exactly match a NET object in ARIN Whois - inet6num objects must exactly match a NET object in ARIN Whois No inetnum or inet6num object may be asserted in ARIN IRR if it does not already exist in ARIN Whois. Why? Because this is how "bad actors" have abused RIPEdb and other wide open IRRs to perform one critical function of setting up a malevolent operation. RIPE's db-wg has been having this discussion, and there is very clear consensus on the rules I propose above The second level of abstraction is authorization. As Jason writes: > For ARIN direct allocations, ARIN direct assignments,and ARIN assigned > ASes, the relationship is strongest. ARIN knows the OrgID, ARIN has > contact info, and ARIN interacts with the Organization at least once a > year for payment. These resources can be managed by any ARIN Online > account linked to the Org. A rule that I think would make sense: - maintainer objects are always authorized by the ORG objects in Whois. This is obvious. What is less obvious is that you want to authorize scripting to ADD/UPDATE/DELETE objects under your maintainer. So something like: - While authorized contacts can add NIC handles to maintainers, notifications (notify:) for the maintainer object must always be sent to the current ORG pocs to ensure they are aware of changes. Now Jason brings up data integrity > 1. First, there is some overlapping data in ARIN WHOIS and ARIN IRR. > It should be impossible for these to be out of sync. Agreed. > - If a resource's ARIN WHOIS information is updated, if there is IRR data > it must also be updated. Agreed. But with forewarning. > - If a resource is revoked / marked stale in WHOIS , the IRR (if it > exists) must also be revoked / marked. Absolutely, and obvious to everyone I hope. > 2. ARIN knows who can manage the resources of a given OrgID based on > linked ARIN Online accounts and API keys those accounts have created. > These same accounts / API Keys should be the ones that can manage IRR > data either through ARIN online or a more traditional way that is tied > back to the ARIN online account. Gotta speak up here for "more traditional". Every operator I've ever been at still does this the old and reliable way: email, with cryto signatures. At scale, it makes sense to have an API for all this, and leverage the API KEY infrastructure already in ARIN Whois. But for discrete changes (which affect the majority of IRR users), email needs to remain an option, in my opinion. > - If a resource is transfered and that is reflected in the WHOIS, > ownership of the IRR data must like wise be transfered. Ding ding ding! Nice thinking, Jason. > 3. When an IRR contains a relationship between two or more resources > that have different owners is authorization from both required? (i think > we have to sort this out a bit. Please Help) No. There is no need for IRR to worry about multiple parties. Just like SWIP, if authorization exists, authorization exists. > 3.a. Should a route holder be able to to designate an origin AS that > they do not hold without the AS holder's acknowledgment? (maybe) The autnum and related objects need some real discussion here. Like Jason, I suspect the answer is maybe, but I don't know enough to know. I can rope in experts into this thread if you need us to. > 3.b. Should an AS holder be able to designate their AS as an origin for > a route they > do not hold with out the route holder's acknowledgement? > (no. they can do all the work and just get the route holder to ack > it though) Disagree here, because if the route object is valid, the IRR doesn't need to authorize the AS relationship. But that's all part of "the autnum and related objects need some real discussion here". > 3.c. Should a route holder be able to remove an origin AS from their > route without the AS holder's acknowledgment? (yes) Yes > > 3.d. Should a route holder be able to adjust the routing policy > associated with someone else's AS, but only with respect to their route without AS > holders acknowledgment ? (no) Didn't grok the situation you're describing. > 3.e. Should an AS holder be able to document a Peering relationship, > transit customer relationship, or transit provider relationship with another > AS without that AS holder's approval? (maybe yes) Yes but same as above. David _______________________________________________ ARIN-Consult You are receiving this message because you are subscribed to the ARIN Consult Mailing List (ARIN-consult at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Wed Jan 31 11:22:52 2018 From: info at arin.net (ARIN) Date: Wed, 31 Jan 2018 11:22:52 -0500 Subject: [ARIN-consult] Consultation on ARIN IRR Roadmap Extended through 25 April 2018 Message-ID: Based on the level of community interest and the significance of the work involved in improving the ARIN Internet Routing Registry (IRR), we are extending the discussion period on the current consultation through 25 April 2018. The consultation text is available at: https://www.arin.net/participate/acsp/community_consult/01-09-2018_irr.html This extension will allow time for ARIN staff to present on this topic at both the North American Network Operators Group (NANOG) meeting, 19-21 February in Atlanta, GA and at the upcoming ARIN 41 Public Policy and Members Meeting, 15-18 April in Miami, Fl. For details on both events, including remote participation options, visit: NANOG 72: https://www.nanog.org/ Presentation on 20 February at 10:00 AM EDT ARIN 41: https://www.arin.net/ARIN41 We encourage all interested individuals to provide comments to arin-consult at arin.net. You can subscribe to this mailing list at: http://lists.arin.net/mailman/listinfo/arin-consult. Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN)