Re: ARIN / RIR Pragmatism (WAS: Re: RADB)
On Oct 27, 2014, at 12:58 AM, Randy Bush ra...@psg.com wrote: LACNIC numbers (as a percent) are quite good, but my question was why only RIPE has the very impressive total count of ROAs. conjecture follows of course one can never know. but i conject o the are the largest registry actively promotin registration o the ncc, particularly alex, tim, oleg, ... have put significant effort into making it very easy to register o they have a culture of cooperation and doing things well Reasonable conjecture; implies that in this region we need to overcome our interesting legal situation, make things easy to use, and then do some significant promotion. You can clearly point to ARIN's legal treatment of the risks involved, but that is not applicable in the APNIC case it is hard to register in apnic, ask folk who have tried. the most active folk are under NIRs, who are only now working on deployment. apnic is not really promoting it. Ah, good to know (and reinforces potential ARIN issues beyond legal wrangling) You don't feel there's any correlation between RIPE's IRR approach and their RPKI success? that's the cooperative culture bit, actually interested in the net running well. Presumably the NANOG community is also interested in keeping the net running well, so if ARIN can provide some reasonably usable services, that shouldn't be an issue. Thanks! /John John Curran President and CEO ARIN
Re: ARIN / RIR Pragmatism (WAS: Re: RADB)
john To what extent is the ROA growth rate in the RIPE region (on page 5 of the NANOG slides) enabled by the IRR practices of that region? check out slide 3, lacnic has a 20% adoption rate. both ripe and lacnic have put energy into their own systems, educating users, ... ripe's curve would not seem to show correlation with recent liberalization of policy, but i doubt it is wise to twy to squeeze cause out of curves. I do recognize that there are issues (as Wes nicely identified in Baltimore and which we'll be working on) that get in the way of RPKI deployment in the ARIN region, but those issues are not present other non-RIPE regions - yet the number actual ROA's issued still appears to be rather low... 20% coverage in lacnic low? how do ipv6 and dnssec compare (which is damned sad)? over 2,000 in ripe and over 8%? how does that compare to ipv6? arin, 388 and 0.7%, a joke. slide 5 It’s What Happens When You Let Lawyers and Wannabe Regulators Run the Internet i really loved the arin ac guy i met in baltimore who did not think having arin meet at nanog was good because those operators just did not get how to regulate the internet. you've been captured by the tea party. randy
Re: ARIN / RIR Pragmatism (WAS: Re: RADB)
On Oct 26, 2014, at 6:46 AM, Randy Bush ra...@psg.com wrote: 20% coverage in lacnic low? how do ipv6 and dnssec compare (which is damned sad)? over 2,000 in ripe and over 8%? how does that compare to ipv6? arin, 388 and 0.7%, a joke. LACNIC numbers (as a percent) are quite good, but my question was why only RIPE has the very impressive total count of ROAs. You can clearly point to ARIN's legal treatment of the risks involved, but that is not applicable in the APNIC case You don't feel there's any correlation between RIPE's IRR approach and their RPKI success? /John John Curran President and CEO ARIN
Re: ARIN / RIR Pragmatism (WAS: Re: RADB)
it's just a consequence that our initial idea was just about to protect allocations of our members - not about secure routing at all On 26 Oct 2014, at 14:40, John Curran jcur...@arin.net wrote: On Oct 26, 2014, at 6:46 AM, Randy Bush ra...@psg.com wrote: 20% coverage in lacnic low? how do ipv6 and dnssec compare (which is damned sad)? over 2,000 in ripe and over 8%? how does that compare to ipv6? arin, 388 and 0.7%, a joke. LACNIC numbers (as a percent) are quite good, but my question was why only RIPE has the very impressive total count of ROAs. You can clearly point to ARIN's legal treatment of the risks involved, but that is not applicable in the APNIC case You don't feel there's any correlation between RIPE's IRR approach and their RPKI success? /John John Curran President and CEO ARIN
Re: ARIN / RIR Pragmatism (WAS: Re: RADB)
John - it is not about RPK I - our initial goal was to deploy some kind of certification to resources allocated to our members Dmitry If we use for it some SIDR developments - may be - it is a mistake or misentrepration - but what's true that we never thougy On 26 Oct 2014, at 14:40, John Curran jcur...@arin.net wrote: On Oct 26, 2014, at 6:46 AM, Randy Bush ra...@psg.com wrote: 20% coverage in lacnic low? how do ipv6 and dnssec compare (which is damned sad)? over 2,000 in ripe and over 8%? how does that compare to ipv6? arin, 388 and 0.7%, a joke. LACNIC numbers (as a percent) are quite good, but my question was why only RIPE has the very impressive total count of ROAs. You can clearly point to ARIN's legal treatment of the risks involved, but that is not applicable in the APNIC case You don't feel there's any correlation between RIPE's IRR approach and their RPKI success? /John John Curran President and CEO ARIN
Re: ARIN / RIR Pragmatism (WAS: Re: RADB)
LACNIC numbers (as a percent) are quite good, but my question was why only RIPE has the very impressive total count of ROAs. conjecture follows of course one can never know. but i conject o the are the largest registry actively promotin registration o the ncc, particularly alex, tim, oleg, ... have put significant effort into making it very easy to register o they have a culture of cooperation and doing things well You can clearly point to ARIN's legal treatment of the risks involved, but that is not applicable in the APNIC case it is hard to register in apnic, ask folk who have tried. the most active folk are under NIRs, who are only now working on deployment. apnic is not really promoting it. You don't feel there's any correlation between RIPE's IRR approach and their RPKI success? that's the cooperative culture bit, actually interested in the net running well. randy
Re: ARIN / RIR Pragmatism (WAS: Re: RADB)
On 2014-10-24 15:24, Christopher Morrow wrote: it seems to me that there are a couple simple issues with IRR data (historically): 1) no authority for it (really, at least in the ARIN region) 2) no common practice of keeping it updated 3) proxy-registration issues (probably part of cleanup and authority issues) 4) lack of widespread use due to the above issues. I think that's a subset of the issues. Those and others are captured here: https://tools.ietf.org/html/draft-ietf-grow-irr-routing-policy-considerations-05 Ironically, many of the issues that lead to decay in IRR use have been resolved, while others exist in RPKI, even. Baldur's RIPE IRR point is a fair one and worthy of consideration, I'm all for low-hanging fruit. I was/am hopeful that providing some path from IANA (eventually) on down through RIR to LIR to end-user for 'authority to use' ip resources would help in letting people use the IRR data cleansed of insanity by the data from this path, and then into routers for route filters. And datapath filters for inter-domain anti-spoofing, perhaps, as it's largely the same policy (I know there are corner cases people that don't want to do this point out). The RPKI system looks like the path in question, to me. I know you're an RPKI fan, I'm at peace with that :-) However, unless you can fortify the systems that RPKI (or any other resource certification infrastructure) would inform, operators have little incentive to use it as all the systems that are already deployed and still have to use (e.g., whois, in-addr.arpa, IRR, etc.) still have to be used and managed and operated. RPKI adds considerable complexity, costs, scaling challenges, new external dependencies, etc.. I actually think it'd have been a challenge to design something _more complicated than RPKI to address the problem space, but that's just me. -danny
Re: ARIN / RIR Pragmatism (WAS: Re: RADB)
Other RIR based RIRs have the same ability to protect prefixes in their realm of control. (See RFC 2725 RPSS)(*) (I think that APNIC is doing pretty much as RIPE is.) Even RIPE is not secure for prefixes outside their region. (There's one maintainer that anyone can use to register anything for resources outside the region - password publicly available, etc.) Non-RIR based IRRs do not have the ability to tie the register-er to authority for the resource, so they have no base on which to build the RIPE sort of security. --Sandy (*) (yes, I'm listed as an author, but Curtis Villamizer was far and away the principal author.) On Oct 24, 2014, at 7:20 PM, Baldur Norddahl baldur.nordd...@gmail.com wrote: The RIPE IRR is secure. Why not just copy that for the other regions? Baldur signature.asc Description: Message signed with OpenPGP using GPGMail
Re: ARIN / RIR Pragmatism (WAS: Re: RADB)
On Oct 25, 2014, at 9:38 PM, Danny McPherson da...@tcb.net wrote: On 2014-10-24 15:24, Christopher Morrow wrote: it seems to me that there are a couple simple issues with IRR data (historically): 1) no authority for it (really, at least in the ARIN region) 2) no common practice of keeping it updated 3) proxy-registration issues (probably part of cleanup and authority issues) 4) lack of widespread use due to the above issues. I think that's a subset of the issues. Those and others are captured here: https://tools.ietf.org/html/draft-ietf-grow-irr-routing-policy-considerations-05 Ironically, many of the issues that lead to decay in IRR use have been resolved, while others exist in RPKI, even. Baldur's RIPE IRR point is a fair one and worthy of consideration, I'm all for low-hanging fruit. I was/am hopeful that providing some path from IANA (eventually) on down through RIR to LIR to end-user for 'authority to use' ip resources would help in letting people use the IRR data cleansed of insanity by the data from this path, and then into routers for route filters. And datapath filters for inter-domain anti-spoofing, perhaps, as it's largely the same policy (I know there are corner cases people that don't want to do this point out). The RPKI system looks like the path in question, to me. I know you're an RPKI fan, I'm at peace with that :-) However, unless you can fortify the systems that RPKI (or any other resource certification infrastructure) would inform, operators have little incentive to use it as all the systems that are already deployed and still have to use (e.g., whois, in-addr.arpa, IRR, etc.) still have to be used and managed and operated. RPKI adds considerable complexity, costs, scaling challenges, new external dependencies, etc.. I actually think it'd have been a challenge to design something _more complicated than RPKI to address the problem space, but that's just me. I had dinner with Russ and Wes during the LA ICANN meeting, and asked, in passing, whether RPKI conferred any benefits that just throwing appropriate IRR records into a signed in-addr didn’t, and they had an answer in the affirmative, but I can’t remember the details now, because I was jet-lagged and it was in the middle of a conversation about something else. Russ, Wes, anyone else with an interest, could you explain that again? -Bill signature.asc Description: Message signed with OpenPGP using GPGMail
Re: ARIN / RIR Pragmatism (WAS: Re: RADB)
On Oct 23, 2014, at 4:18 PM, Danny McPherson da...@tcb.net wrote: On 2014-10-23 12:33, Christopher Morrow wrote: Sounds like you want to see the rirs make sure they get rpki work dine and widely available with the least encumbrances on the network operator community as possible. Or focus on more short/intermediate term returns like fortifying all the existing systems and automating processes that are already deployed and focus on ROI of members and operational buffers required by the community _today. E.g., IRR training and investment rather than RPKI, which this thread began with. I'd continue and say in-addr.arpa or the like for resource certification because RPKI is so ugly, silly without a single root aligned with number resource allocations, etc.., but that'd require response cycles I'm not going to spend there. Just for avoidance of any doubt - The ARIN Board of Trustees has consistently directed that ARIN work on technical capabilities that the community clearly expresses some level of interest in, i.e. there is no standing directive that particular technology solutions must be (or must not be) deployed. We have had very specific requests for supporting RPKI, so we've done the necessary work for hosted and delegated certificate authority (CA) services. We can continue to enhance RPKI, or deploy other technical solutions, or some combination (as the community directs) With respect to IRR support, the same answer applies. If the community is clear on direction, ARIN can strengthen the current IRR offerings, phase them out and redirect folks to existing solutions, or any other direction as desired. The hardest part is getting a common view in the community on the desired approach; this leads to the strong adoption that is necessary for these types of systems to have meaningful benefit. FYI, /John John Curran President and CEO ARIN
Re: ARIN / RIR Pragmatism (WAS: Re: RADB)
On 2014-10-25 08:25, John Curran wrote: With respect to IRR support, the same answer applies. If the community is clear on direction, ARIN can strengthen the current IRR offerings, phase them out and redirect folks to existing solutions, or any other direction as desired. The hardest part is getting a common view in the community on the desired approach; this leads to the strong adoption that is necessary for these types of systems to have meaningful benefit. I didn't necessarily intend to fault ARIN here, some very vocal folks have pushed ARIN (and others) pretty hard on focusing considerable resources on experimental systems (RPKI [/BGPSEC]) that may never see broad-scale adoption and use, for an array of technical, business, and geopolitical reasons. I could be wrong. As an ARIN and community member, I'd prefer to see more work on nearer term solutions and better leveraging existing systems that we're already captive to and will still need in the future (e.g., IRR hygiene work and more security rails, tool sets, training for operators, perhaps in-addr.arpa or other techniques to validate resource holders, etc..). If orthodox visions materialize that provide utility and a reasonable ROI without introducing excess risk and overhead and complexity and undue external dependencies for the folks that would be captive to those new systems, then great. I continue to believe that the only way any resource certification system is going to realize adoption is by taking this incremental approach of fortifying existing systems and supplying sufficient operational buffers, and that the easiest way to stunt deployment and adoption of RPKI is to slam it directly into the routing system and compromise current autonomy in routing operations that exists and makes the Internet resilient. Thanks for that response, John. -danny
Re: ARIN / RIR Pragmatism (WAS: Re: RADB)
On 2014-10-25 06:57, Sandra Murphy wrote: Other RIR based RIRs have the same ability to protect prefixes in their realm of control. (See RFC 2725 RPSS)(*) (I think that APNIC is doing pretty much as RIPE is.) Even RIPE is not secure for prefixes outside their region. (There's one maintainer that anyone can use to register anything for resources outside the region - password publicly available, etc.) Non-RIR based IRRs do not have the ability to tie the register-er to authority for the resource, so they have no base on which to build the RIPE sort of security. Those are fair points Sandy, I agree they need to be resolved. It's just that RPKI feels like a _really heavy solution to _that problem. That said, if that problem were solved nearly all of what I care about with regard to routing security (and inter-domain anti-spoofing) could be addressed. -danny
Re: ARIN / RIR Pragmatism (WAS: Re: RADB)
you just happen to have the view from a third world country look at. http://archive.psg.com/141006.rpki-nanog.pdf slides 4 5 or http://certification-stats.ripe.net/?type=roa-v4 randy
Re: ARIN / RIR Pragmatism (WAS: Re: RADB)
On Sat, Oct 25, 2014 at 5:00 PM, Randy Bush ra...@psg.com wrote: you just happen to have the view from a third world country look at. http://archive.psg.com/141006.rpki-nanog.pdf slides 4 5 or http://certification-stats.ripe.net/?type=roa-v4 randy I agree with Randy. RPKI is achievable today. Signing routes is a trivial amount of effort, there is really no excuse to not do it. Even i did it. Validation does take effort, but it is consistent with the level of effort to deploy any new router feature. CB
Re: ARIN / RIR Pragmatism (WAS: Re: RADB)
On Oct 25, 2014, at 8:00 PM, Randy Bush ra...@psg.com wrote: you just happen to have the view from a third world country look at. http://archive.psg.com/141006.rpki-nanog.pdf slides 4 5 or http://certification-stats.ripe.net/?type=roa-v4 Randy - To what extent is the ROA growth rate in the RIPE region (on page 5 of the NANOG slides) enabled by the IRR practices of that region? I do recognize that there are issues (as Wes nicely identified in Baltimore and which we'll be working on) that get in the way of RPKI deployment in the ARIN region, but those issues are not present other non-RIPE regions - yet the number actual ROA's issued still appears to be rather low... Thoughts? /John John Curran President and CEO ARIN
Re: ARIN / RIR Pragmatism (WAS: Re: RADB)
On Thu, Oct 23, 2014 at 4:18 PM, Danny McPherson da...@tcb.net wrote: On 2014-10-23 12:33, Christopher Morrow wrote: Sounds like you want to see the rirs make sure they get rpki work dine and widely available with the least encumbrances on the network operator community as possible. Or focus on more short/intermediate term returns like fortifying all the existing systems and automating processes that are already deployed and focus on ROI of members and operational buffers required by the community _today. E.g., IRR training and investment rather than RPKI, which this thread began with. makes perfect sense to focus on validating existing systems such as IRR. Seems like very low hanging fruit with a lot of benefit and a good ROI I'd continue and say in-addr.arpa or the like for resource certification because RPKI is so ugly, silly without a single root aligned with number resource allocations, etc.., but that'd require response cycles I'm not going to spend there. Did you see wes's slides / talk at the last nanog? I did (after). Aside, I understand why the ARIN board did what they did with the RPA and I don't blame them -- it seemed well considered to me, but that's just me. Reminded of Taleb's Fat Tony quote [paraphrased]: If the pilot ain't on the plane, you probably don't want to get on it, -danny
Re: ARIN / RIR Pragmatism (WAS: Re: RADB)
On Fri, Oct 24, 2014 at 8:23 AM, John Sweeting john.sweet...@gmail.com wrote: On Thu, Oct 23, 2014 at 4:18 PM, Danny McPherson da...@tcb.net wrote: On 2014-10-23 12:33, Christopher Morrow wrote: Sounds like you want to see the rirs make sure they get rpki work dine and widely available with the least encumbrances on the network operator community as possible. Or focus on more short/intermediate term returns like fortifying all the existing systems and automating processes that are already deployed and focus on ROI of members and operational buffers required by the community _today. E.g., IRR training and investment rather than RPKI, which this thread began with. makes perfect sense to focus on validating existing systems such as IRR. Seems like very low hanging fruit with a lot of benefit and a good ROI it seems to me that there are a couple simple issues with IRR data (historically): 1) no authority for it (really, at least in the ARIN region) 2) no common practice of keeping it updated 3) proxy-registration issues (probably part of cleanup and authority issues) 4) lack of widespread use due to the above issues. I was/am hopeful that providing some path from IANA (eventually) on down through RIR to LIR to end-user for 'authority to use' ip resources would help in letting people use the IRR data cleansed of insanity by the data from this path, and then into routers for route filters. The RPKI system looks like the path in question, to me. I'd continue and say in-addr.arpa or the like for resource certification because RPKI is so ugly, silly without a single root aligned with number resource allocations, etc.., but that'd require response cycles I'm not going to spend there. Did you see wes's slides / talk at the last nanog? I did (after). Aside, I understand why the ARIN board did what they did with the RPA and I don't blame them -- it seemed well considered to me, but that's just me. Reminded of Taleb's Fat Tony quote [paraphrased]: If the pilot ain't on the plane, you probably don't want to get on it, -danny
Re: ARIN / RIR Pragmatism (WAS: Re: RADB)
The RIPE IRR is secure. Why not just copy that for the other regions? Baldur
ARIN / RIR Pragmatism (WAS: Re: RADB)
soapbox I think the routing system would be in a much happier [less bad] place if only had a minor amount of the energy and resources that USG (and RIRs) have been put towards RPKI and BGPSEC (i.e., IETF SIDR work) would have been redirected to lower hanging fruit and better recognizing / leveraging existent systems and operational practices (e.g., more IRR usage, training, tools, and better hygiene, perhaps expressly validated from resource certification from either RPKI or in-addr.arpa, etc). Given that many of the same derived policies there could also be employed for inter-domain datapath anti-spoofing (BCP38-ish inter-domain) and that all the existing machinery and practices already deployed could more easily accommodate this in the near term, it seems only natural to me. As for the visionaries playing the long game, they've made progress, but surely the only way to get there is with more incremental putty and small practical steps to fill the gaps at this point. /soapbox I for one would like to see ARIN (as well as other RIRs and the adjacent community) invest more pragmatically in this area, particularly given the governance climate and other externalities at play these days. Alas, -danny
Re: ARIN / RIR Pragmatism (WAS: Re: RADB)
On Oct 23, 2014 2:27 PM, Danny McPherson da...@tcb.net wrote: soapbox I think the routing system would be in a much happier [less bad] place if only had a minor amount of the energy and resources that USG (and RIRs) have been put towards RPKI and BGPSEC (i.e., IETF SIDR work) would have been redirected to lower hanging fruit and better recognizing / leveraging existent systems and operational practices (e.g., more IRR usage, training, tools, and better hygiene, perhaps expressly validated from resource certification from either RPKI or in-addr.arpa, etc). Given that many of the same derived policies there could also be employed for inter-domain datapath anti-spoofing (BCP38-ish inter-domain) and that all the existing machinery and practices already deployed could more easily accommodate this in the near term, it seems only natural to me. As for the visionaries playing the long game, they've made progress, but surely the only way to get there is with more incremental putty and small practical steps to fill the gaps at this point. /soapbox I for one would like to see ARIN (as well as other RIRs and the adjacent community) invest more pragmatically in this area, particularly given the governance climate and other externalities at play these days. Sounds like you want to see the rirs make sure they get rpki work dine and widely available with the least encumbrances on the network operator community as possible. Did you see wes's slides / talk at the last nanog? Alas, -danny
Re: ARIN / RIR Pragmatism (WAS: Re: RADB)
On 2014-10-23 12:33, Christopher Morrow wrote: Sounds like you want to see the rirs make sure they get rpki work dine and widely available with the least encumbrances on the network operator community as possible. Or focus on more short/intermediate term returns like fortifying all the existing systems and automating processes that are already deployed and focus on ROI of members and operational buffers required by the community _today. E.g., IRR training and investment rather than RPKI, which this thread began with. I'd continue and say in-addr.arpa or the like for resource certification because RPKI is so ugly, silly without a single root aligned with number resource allocations, etc.., but that'd require response cycles I'm not going to spend there. Did you see wes's slides / talk at the last nanog? I did (after). Aside, I understand why the ARIN board did what they did with the RPA and I don't blame them -- it seemed well considered to me, but that's just me. Reminded of Taleb's Fat Tony quote [paraphrased]: If the pilot ain't on the plane, you probably don't want to get on it, -danny
Re: ARIN / RIR Pragmatism (WAS: Re: RADB)
IRR usage, training, tools, and better hygiene, perhaps expressly validated from resource certification from either RPKI You might be interested in the draft-ietf-sidr-rpsl-sig-05.txt, which suggests using RPKI to protect RPSL objects. That would help solve the trust problem in the current IRR world, which is that most IRRs can't tell if the object being registered is authorized. RIPE and, I think, APNIC being the exception, for their region resources. Lots of proxy registered objects aren't a good sign. --Sandy On Oct 23, 2014, at 2:26 PM, Danny McPherson da...@tcb.net wrote: soapbox I think the routing system would be in a much happier [less bad] place if only had a minor amount of the energy and resources that USG (and RIRs) have been put towards RPKI and BGPSEC (i.e., IETF SIDR work) would have been redirected to lower hanging fruit and better recognizing / leveraging existent systems and operational practices (e.g., more IRR usage, training, tools, and better hygiene, perhaps expressly validated from resource certification from either RPKI or in-addr.arpa, etc). Given that many of the same derived policies there could also be employed for inter-domain datapath anti-spoofing (BCP38-ish inter-domain) and that all the existing machinery and practices already deployed could more easily accommodate this in the near term, it seems only natural to me. As for the visionaries playing the long game, they've made progress, but surely the only way to get there is with more incremental putty and small practical steps to fill the gaps at this point. /soapbox I for one would like to see ARIN (as well as other RIRs and the adjacent community) invest more pragmatically in this area, particularly given the governance climate and other externalities at play these days. Alas, -danny signature.asc Description: Message signed with OpenPGP using GPGMail
Re: ARIN / RIR Pragmatism (WAS: Re: RADB)
On 2014-10-23 15:02, Sandra Murphy wrote: IRR usage, training, tools, and better hygiene, perhaps expressly validated from resource certification from either RPKI You might be interested in the draft-ietf-sidr-rpsl-sig-05.txt, which suggests using RPKI to protect RPSL objects. Yep, I'm aware of that and think that's a really useful thing if RPKI is the resource certification infrastructure we must use. That would help solve the trust problem in the current IRR world, which is that most IRRs can't tell if the object being registered is authorized. RIPE and, I think, APNIC being the exception, for their region resources. Lots of proxy registered objects aren't a good sign. Agreed! That said, if people are still having issues with IRRs and lack of training, toolsets, and usability around them today and after deploying RPKI they still need IRRs (and whois, and in-addr.arpa, and..) for a whole bunch of stuff just to keep the packets flowing then the height limit to do basic and useful things just became that much higher, and requires a lot more care and feeding then before RPKI (even absent all the architectural aspects of RPKI that are interesting). -danny
