Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
In my presentation in APNIC, I suggested that as a possible option. Why not? There is a lot of cooperation among the RIRs, and this may be one more way to do so. Or this may be run somehow via the NRO, or we can ask IANA to do it for the NRO. If we don't trust in the cooperation among the RIRs, then is better we close the doors of all the RIRs and go to the wild west. I also suggested one more action. Even if all the 5 RIRs adopt this policy, there is space still unallocated space on the hands of IANA, specially for IPv6. I'm considering drafting a global policy for that. This global policy in fact, could be done even if the policy is not adopted in all the RIRs, but of course I think it will be then more difficult to reach consensus. Another possible alternative is doing it from the IETF (so the IETF instructs IANA to do it). El 4/3/20 12:37, "routing-wg en nombre de Nick Hilliard" escribió: Carlos Friaças via routing-wg wrote on 04/03/2020 07:23: > Unfortunately, you will only "run AS0" over non-distributed APNIC space. > > If you were able to do it for the full problem space, those who will > continue to explore this weakness in the global routing system would not > have an excellent alternative by simply choosing to abuse > non-distributed space by the other RIRs... Carlos, are you seriously suggesting that APNIC or any other RIR should use a TAL for 0/0 to claim authority over unallocated space from other RIRs? This would be an extraordinary breach of trust in the RIR community. Nick ** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Hi Job, If someone want to ignore people using bogons for bad things, then of course, they have "no cost", but in general I believe most of the operators use someway to filter bogons. RPKI can help on that. RPKI is a secure and automated way to have that information. The SLURM file is not secure. We can of course find the way to secure it, but that keep increasing the cost of using it (and publishing it). El 3/3/20 19:42, "routing-wg en nombre de Job Snijders" escribió: Hi, On Tue, Mar 3, 2020, at 19:31, JORDI PALET MARTINEZ via routing-wg wrote: > I don't think I'm the one that should calculate that. However, if we > have an alternative proposal with the SLURM file, it can be calculated > (approximately) as part of the analysis impact that will be needed as > well, right? > > May be anyone from the community that already has done that job and > integrated the SLURM in their routers, can provide an estimate cost, > and then multiply it for the number of all the RIRs members? > > I believe (I may be wrong) that the AS0 is much cheaper to implement by > RIPE NCC even if it is several thousand euros, than the number of > worldwide folks that will need to use the SLURM in addition to RPKI > (for non-AS0). Let me rephrase: what is the cost to the community of no implementation of 2019-08 at all? It has been mentioned before that 2019-08 in its current shape seems way too big of a hammer for the problem it claims to solve. I personally consider a SLURM file a good middle-ground, but if it boils down either using the RPKI for this or nothing, the latter option is what I support. Kind regards, Job ** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Carlos Friaças wrote on 04/03/2020 20:28: I wonder what would happen if *one* community at some point decides to ask their RIR to "please throw in also the unallocated/unassigned blocks (junk) from other RIRs, while you are at it" :-) apart from causing a political supernova at all the other RIRs? Job answered this question earlier today. Nick
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
On Wed, 4 Mar 2020, Nick Hilliard wrote: Carlos Friaças via routing-wg wrote on 04/03/2020 07:23: Unfortunately, you will only "run AS0" over non-distributed APNIC space. If you were able to do it for the full problem space, those who will continue to explore this weakness in the global routing system would not have an excellent alternative by simply choosing to abuse non-distributed space by the other RIRs... Carlos, are you seriously suggesting that APNIC or any other RIR should use a TAL for 0/0 to claim authority over unallocated space from other RIRs? Nick, All, What did cross my mind was that if *one* RIR was going to double the not-so-cheap infrastructure, maybe, with enough levels of coordination with other RIRs (and a cost-sharing model), the cost could be (globally) smaller. i.e. ((1+1) x 5 RIRs) vs. ((1 x 5 RIRs) + 1 by APNIC). This would be an extraordinary breach of trust in the RIR community. Between RIR communities? I wonder what would happen if *one* community at some point decides to ask their RIR to "please throw in also the unallocated/unassigned blocks (junk) from other RIRs, while you are at it" :-) Carlos Nick
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
while i am tempted toward the slurm approach, i wonder what authenticates the slurm file(s)? randy
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
>> in their arrogance, the rirs already do that :( > > this is the problem. If the TAL covers all address space then it > needs to be handled carefully and Thiago's email from a couple of days > ago outlined their rationale why. > > If TAL doesn't cover all address space then it's much easier, but that > makes transfers difficult. not exactly. what makes transfers (and this) difficult is the rirs pissing contest with the iana. more arrogance, on both parts; to the detriment of the internet. randy
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Randy Bush wrote on 04/03/2020 16:38: in their arrogance, the rirs already do that :( this is the problem. If the TAL covers all address space then it needs to be handled carefully and Thiago's email from a couple of days ago outlined their rationale why. If TAL doesn't cover all address space then it's much easier, but that makes transfers difficult. Nick
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
>> would this duplication of infrastructure actually be needed or >> useful? the american idiom is "making a mountain out of a molehill" > would the TAL be for 0/0 and ::/0? in their arrogance, the rirs already do that :( randy
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
On Wed, Mar 04, 2020 at 11:36:55AM +, Nick Hilliard wrote: > Carlos Friaças via routing-wg wrote on 04/03/2020 07:23: > > Unfortunately, you will only "run AS0" over non-distributed APNIC space. > > > > If you were able to do it for the full problem space, those who will > > continue to explore this weakness in the global routing system would not > > have an excellent alternative by simply choosing to abuse > > non-distributed space by the other RIRs... > > are you seriously suggesting that APNIC or any other RIR should use a TAL > for 0/0 to claim authority over unallocated space from other RIRs? > > This would be an extraordinary breach of trust in the RIR community. Should any RIR would start interfering with potentially unassigned or unallocated resources from another RIR in such a manner, I'd consider the RIR CA akin to compromised and suggest to remove the associated TAL from our RPKI Cache Validators. Thus the outlined approach would result in negative impact for the NIRs and LIRs under that RIR CA in the affected region, but probably outweighs the complications of one RIR claiming space is Unassigned/Unallocated while the actual managing RIR might think otherwise. In short, this would be a misuse of the current certificate structure that that implemented 0.0.0.0/0 + ::/0 to facilitate inter-RIR transfers. That mechanism was not intended to help RIRs step on each other's toes. Let's continue to focus on deploying RPKI Origin Validation as-is on all Internet EBGP sessions first. At best it seems premature to overload the functionality of the RPKI in this way. Kind regards, Job
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Randy Bush wrote on 03/03/2020 21:34: would this duplication of infrastructure actually be needed or useful? the american idiom is "making a mountain out of a molehill" would the TAL be for 0/0 and ::/0? What's the PKI trust model for this arrangement? Nick
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Carlos Friaças via routing-wg wrote on 04/03/2020 07:23: Unfortunately, you will only "run AS0" over non-distributed APNIC space. If you were able to do it for the full problem space, those who will continue to explore this weakness in the global routing system would not have an excellent alternative by simply choosing to abuse non-distributed space by the other RIRs... Carlos, are you seriously suggesting that APNIC or any other RIR should use a TAL for 0/0 to claim authority over unallocated space from other RIRs? This would be an extraordinary breach of trust in the RIR community. Nick
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
George, many thanks for your input. (please see inline) On Wed, 4 Mar 2020, George Michaelson wrote: As a point of information, APNIC secretariat is still considering what to do here, having direction from the membership to run AS0 but open issues around how we do that operationally. Unfortunately, you will only "run AS0" over non-distributed APNIC space. If you were able to do it for the full problem space, those who will continue to explore this weakness in the global routing system would not have an excellent alternative by simply choosing to abuse non-distributed space by the other RIRs... We got to a split TA. The community seemed ok with that. We got to the model of how we're deploying. We have a testbed. What actual "live" deployment looks like is still a bit un-baked. HSM: Back the AS0 on a real HSM or not (ie "soft" TA keypair) pro: things we say in AS0 should be considered as important as things we see on mainline con: its a huge investment for something the community is considering marginal value compared to e.g. SLURM file. Soft TA may simply be more appropriate. Maybe the SLURM file trade-off is a good one (and it's availability seems inevitably positive), but if RPKI's takeup is slow, the SLURM file usage will be even slower... :-( Shared HSM vs independent HSM: Do we duplicate systems or re-use the same platform? pro: cheaper to share. con: shared fate! if you operationally mistake things on the AS0 "side" of the shared systems, and its in FIPS mode, is the non-AS0 side now lost because of it ? that is bad. I tend to saying "if we HSM, and cannot ensure its a virtual slice with no real risk of information/key loss, then re-using the same HSM is a higher risk than I like" which drives to a higher cost, but more safe. Fully agree. "Safe" (or "safer") generally comes with a price tag... Overall I prefer less interaction on the TA. I want to do as little on the TA as sensible. I don't want to share fate if I can avoid it, purely from a risk management perspective. If I got feedback in my community they don't feel this needs HSM backing, I can avoid the problem. I probably need to go seek that in the right space for APNIC but I welcome the consensus emerging here, it is very helpful to me. Will abstain to comment about consensus :-) Regards, Carlos -George
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
As a point of information, APNIC secretariat is still considering what to do here, having direction from the membership to run AS0 but open issues around how we do that operationally. We got to a split TA. The community seemed ok with that. We got to the model of how we're deploying. We have a testbed. What actual "live" deployment looks like is still a bit un-baked. HSM: Back the AS0 on a real HSM or not (ie "soft" TA keypair) pro: things we say in AS0 should be considered as important as things we see on mainline con: its a huge investment for something the community is considering marginal value compared to e.g. SLURM file. Soft TA may simply be more appropriate. Shared HSM vs independent HSM: Do we duplicate systems or re-use the same platform? pro: cheaper to share. con: shared fate! if you operationally mistake things on the AS0 "side" of the shared systems, and its in FIPS mode, is the non-AS0 side now lost because of it ? that is bad. I tend to saying "if we HSM, and cannot ensure its a virtual slice with no real risk of information/key loss, then re-using the same HSM is a higher risk than I like" which drives to a higher cost, but more safe. Overall I prefer less interaction on the TA. I want to do as little on the TA as sensible. I don't want to share fate if I can avoid it, purely from a risk management perspective. If I got feedback in my community they don't feel this needs HSM backing, I can avoid the problem. I probably need to go seek that in the right space for APNIC but I welcome the consensus emerging here, it is very helpful to me. -George On Wed, Mar 4, 2020 at 7:34 AM Randy Bush wrote: > > >> Let me rephrase: what is the cost to the community of no > >> implementation of 2019-08 at all? > >> > >> [...] but if it boils down either using the RPKI for this or nothing, > >> the latter option is what I support. > > > > Pretty much that. > > yep > > but ... > > > They've made it clear that the costs will be substantial, including: > > - duplication of the entire RPKI infrastructure > > - 6m wall clock time for some of the software team > > - additional internal / external processes + documentation > > would this duplication of infrastructure actually be needed or useful? > the american idiom is "making a mountain out of a molehill" > > randy >
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
>> Let me rephrase: what is the cost to the community of no >> implementation of 2019-08 at all? >> >> [...] but if it boils down either using the RPKI for this or nothing, >> the latter option is what I support. > > Pretty much that. yep but ... > They've made it clear that the costs will be substantial, including: > - duplication of the entire RPKI infrastructure > - 6m wall clock time for some of the software team > - additional internal / external processes + documentation would this duplication of infrastructure actually be needed or useful? the american idiom is "making a mountain out of a molehill" randy
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Job Snijders wrote on 03/03/2020 18:41: Let me rephrase: what is the cost to the community of no implementation of 2019-08 at all? [...] but if it boils down either using the RPKI for this or nothing, the latter option is what I support. Pretty much that. They've made it clear that the costs will be substantial, including: - duplication of the entire RPKI infrastructure - 6m wall clock time for some of the software team - additional internal / external processes + documentation This isn't a small undertaking - it's substantial. Set against that, the benefit to the proposal is marginal at best, and harmful in some important respects. On top of that, it isn't reasonable for people to hit the RIPE NCC with requests to do more and more ground work on an impact analysis for proposals where it's far from clear that's any consensus to start with. Nick
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Hi, On Tue, Mar 3, 2020, at 19:31, JORDI PALET MARTINEZ via routing-wg wrote: > I don't think I'm the one that should calculate that. However, if we > have an alternative proposal with the SLURM file, it can be calculated > (approximately) as part of the analysis impact that will be needed as > well, right? > > May be anyone from the community that already has done that job and > integrated the SLURM in their routers, can provide an estimate cost, > and then multiply it for the number of all the RIRs members? > > I believe (I may be wrong) that the AS0 is much cheaper to implement by > RIPE NCC even if it is several thousand euros, than the number of > worldwide folks that will need to use the SLURM in addition to RPKI > (for non-AS0). Let me rephrase: what is the cost to the community of no implementation of 2019-08 at all? It has been mentioned before that 2019-08 in its current shape seems way too big of a hammer for the problem it claims to solve. I personally consider a SLURM file a good middle-ground, but if it boils down either using the RPKI for this or nothing, the latter option is what I support. Kind regards, Job
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Hi Job, I don't think I'm the one that should calculate that. However, if we have an alternative proposal with the SLURM file, it can be calculated (approximately) as part of the analysis impact that will be needed as well, right? May be anyone from the community that already has done that job and integrated the SLURM in their routers, can provide an estimate cost, and then multiply it for the number of all the RIRs members? I believe (I may be wrong) that the AS0 is much cheaper to implement by RIPE NCC even if it is several thousand euros, than the number of worldwide folks that will need to use the SLURM in addition to RPKI (for non-AS0). Regards, Jordi @jordipalet El 3/3/20 19:23, "Job Snijders" escribió: Hi Jordi, On Tue, Mar 3, 2020, at 19:20, JORDI PALET MARTINEZ via routing-wg wrote: > I understand that, but I think it may be easy to get an idea, not exact cost. > > The reason why this is needed is because one of the arguments against > this proposal is about the cost. > > This can't be judged as a valid objection for reaching consensus if we > don't have that cost (approximate). Can you provide us with an estimate of the cost to the collective community if this proposal is *not* implemented as RPKI ROAs but just as SLURM file instead? Kind regards, Job ** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Dear Jordi, I would like to clarify that the financial cost approximation of a proposal is not part of the Impact Analysis and the Policy Development Process, so we have not made a calculation. As too many factors have to be taken into account that we can't estimate realistically at this stage of the PDP. Our software department provided an estimation of the worked involved for the implementation of the proposal which is explained in the impact analysis. Kind regards, — Petrit Hasani Policy Officer RIPE NCC > On 2 Mar 2020, at 20:22, JORDI PALET MARTINEZ via routing-wg > wrote: > > Hi Thiago, > > Yeah, I understand that … So, my question is re-directed to the policy > officer for providing an approximation of what is the cost. > > Regards, > Jordi > > @jordipalet > > > > > > El 2/3/20 20:07, "Thiago da Cruz" escribió: > > Hi Jordi, > > I’m not the budget guy, so I’m going to distance myself from the euros. > When I say “it would cost us a lot to implement it” I mean in effort when > compared with other options. > > Kind regards, > Thiago da Cruz > Sr. software engineer - RPKI Team > RIPE NCC > > > >> On 2 Mar 2020, at 18:25, JORDI PALET MARTINEZ via routing-wg >> wrote: >> >> Hi Thiago, >> >> The question here, I think, is to understand how much in euros is “a lot”? >> >> Regards, >> Jordi >> >> @jordipalet >> >> >> >> >> >> El 2/3/20 11:11, "routing-wg en nombre de Thiago da Cruz" >> escribió: >> >> Hi all, >> >> Many of you might not know me, but I’m part of RIPE’s software engineering >> team that takes care of RPKI. >> >> I’ve been following this discussion closely and I've noticed some lack of >> clarity about our decision to duplicate our RPKI infrastructure. >> So I think it’s important for us to tell a few things about our approach. >> >> First what we have today in production: >> - TA software (offline box) >> - HSM for the TA (plus backups and spare parts) >> - A few application servers running our RPKI software - I’ll call it >> RPKI-Core >> - Redundant HSMs used by RPKI-Core >> - RRDP publication service (cloud) >> - Some rsync nodes (internal infra) >> >> Something like the diagram below. >> >> For testing environment we have practically the same infra. >> And for public test (localcert) we use ‘soft' keys and no HSMs. >> >> >> About the new AS0 TA, yes, we could simplify our infra. >> One option would be to use ‘soft’ keys all around or use a HSM for TA only. >> We could also use third-party software for TA, Core and publication service. >> It crossed my mind, for a fraction of a second, to skip AS0 TA instances for >> our internal and/or public test environments. >> >> But I don’t think we should treat it as a "second class citizen". >> If we provide another TA, it’s worthy of receiving as much TLC as our >> production TA; meaning that it would also require the same (or similar) >> process around it as our production TA does. That includes keeping track of >> HSM card holders, defining a proper admin and operator quorum, scheduling >> periodical resigning sessions, etc… >> >> I’m not here to advocate against nor in favour of AS0 TA. >> But when discussing our implementation, this was our rationale to duplicate >> the infrastructure. >> And that’s why it would cost us a lot to implement it. >> >> Let me know you need more info about this subject. >> >> Kind regards, >> Thiago da Cruz >> Sr. software engineer - RPKI Team >> RIPE NCC >> >> >> +-+ >> | |+---+ >> |TA (offline) ++ HSM | >> | |+---+ >> +-+ >> >> >> >> >> >>++ >> >>|| >> >> +---> |RRDP publication| >> >> | || >> >> | |(cloud) | >> >> | || >> +---+ +---+ >> | ++ >> | | | | >> Publication| >> |RPKI-Core 1|(...)|RPKI-Core n| >> --> * +> >> | |
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Hi Thiago, Yeah, I understand that … So, my question is re-directed to the policy officer for providing an approximation of what is the cost. Regards, Jordi @jordipalet El 2/3/20 20:07, "Thiago da Cruz" escribió: Hi Jordi, I’m not the budget guy, so I’m going to distance myself from the euros. When I say “it would cost us a lot to implement it” I mean in effort when compared with other options. Kind regards, Thiago da Cruz Sr. software engineer - RPKI Team RIPE NCC On 2 Mar 2020, at 18:25, JORDI PALET MARTINEZ via routing-wg wrote: Hi Thiago, The question here, I think, is to understand how much in euros is “a lot”? Regards, Jordi @jordipalet El 2/3/20 11:11, "routing-wg en nombre de Thiago da Cruz" escribió: Hi all, Many of you might not know me, but I’m part of RIPE’s software engineering team that takes care of RPKI. I’ve been following this discussion closely and I've noticed some lack of clarity about our decision to duplicate our RPKI infrastructure. So I think it’s important for us to tell a few things about our approach. First what we have today in production: - TA software (offline box) - HSM for the TA (plus backups and spare parts) - A few application servers running our RPKI software - I’ll call it RPKI-Core - Redundant HSMs used by RPKI-Core - RRDP publication service (cloud) - Some rsync nodes (internal infra) Something like the diagram below. For testing environment we have practically the same infra. And for public test (localcert) we use ‘soft' keys and no HSMs. About the new AS0 TA, yes, we could simplify our infra. One option would be to use ‘soft’ keys all around or use a HSM for TA only. We could also use third-party software for TA, Core and publication service. It crossed my mind, for a fraction of a second, to skip AS0 TA instances for our internal and/or public test environments. But I don’t think we should treat it as a "second class citizen". If we provide another TA, it’s worthy of receiving as much TLC as our production TA; meaning that it would also require the same (or similar) process around it as our production TA does. That includes keeping track of HSM card holders, defining a proper admin and operator quorum, scheduling periodical resigning sessions, etc… I’m not here to advocate against nor in favour of AS0 TA. But when discussing our implementation, this was our rationale to duplicate the infrastructure. And that’s why it would cost us a lot to implement it. Let me know you need more info about this subject. Kind regards, Thiago da Cruz Sr. software engineer - RPKI Team RIPE NCC +-+ | |+---+ |TA (offline) ++ HSM | | |+---+ +-+ ++ || +---> |RRDP publication| | || | |(cloud) | | || +---+ +---+ | ++ | | | | Publication| |RPKI-Core 1|(...)|RPKI-Core n| --> * +> | | | | | +--+-++-+ +--+--+---+-+ | ++ | || | | | | || | |+---+ | | | | |Rsync publication | | || | | ++ +---> || +-+ +---+ +-+ || | (internal infra - x nodes) | | | | | |
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Dear Massimiliano, Thank you for the overview and proposing possible paths forward. On Tue, Feb 25, 2020 at 08:30:21PM +0100, Massimiliano Stucchi wrote: > C) We can change the proposal to a different ask for RIPE NCC. The idea > could be to ask RIPE NCC to provide a SLURM file (similar to what APNIC > does), so that single users can decide if they want to feed it to their > validators. I would be in favor of option C - generation of a SLURM file. It appears cheap to implement and efficient in its purpose, it is opt-in. A good balance. Kind regards, Job
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Hi Thiago, The question here, I think, is to understand how much in euros is “a lot”? Regards, Jordi @jordipalet El 2/3/20 11:11, "routing-wg en nombre de Thiago da Cruz" escribió: Hi all, Many of you might not know me, but I’m part of RIPE’s software engineering team that takes care of RPKI. I’ve been following this discussion closely and I've noticed some lack of clarity about our decision to duplicate our RPKI infrastructure. So I think it’s important for us to tell a few things about our approach. First what we have today in production: - TA software (offline box) - HSM for the TA (plus backups and spare parts) - A few application servers running our RPKI software - I’ll call it RPKI-Core - Redundant HSMs used by RPKI-Core - RRDP publication service (cloud) - Some rsync nodes (internal infra) Something like the diagram below. For testing environment we have practically the same infra. And for public test (localcert) we use ‘soft' keys and no HSMs. About the new AS0 TA, yes, we could simplify our infra. One option would be to use ‘soft’ keys all around or use a HSM for TA only. We could also use third-party software for TA, Core and publication service. It crossed my mind, for a fraction of a second, to skip AS0 TA instances for our internal and/or public test environments. But I don’t think we should treat it as a "second class citizen". If we provide another TA, it’s worthy of receiving as much TLC as our production TA; meaning that it would also require the same (or similar) process around it as our production TA does. That includes keeping track of HSM card holders, defining a proper admin and operator quorum, scheduling periodical resigning sessions, etc… I’m not here to advocate against nor in favour of AS0 TA. But when discussing our implementation, this was our rationale to duplicate the infrastructure. And that’s why it would cost us a lot to implement it. Let me know you need more info about this subject. Kind regards, Thiago da Cruz Sr. software engineer - RPKI Team RIPE NCC +-+ | |+---+ |TA (offline) ++ HSM | | |+---+ +-+ ++ || +---> |RRDP publication| | || | |(cloud) | | || +---+ +---+ | ++ | | | | Publication| |RPKI-Core 1|(...)|RPKI-Core n| --> * +> | | | | | +--+-++-+ +--+--+---+-+ | ++ | || | | | | || | |+---+ | | | | |Rsync publication | | || | | ++ +---> || +-+ +---+ +-+ || | (internal infra - x nodes) | | | | | || || | | | +---+ | || |+-+ | | ++ || | | | | +-++--+ + ++-+--++ | HSM 1 | (..) | HSM m | +-+
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Hi guys I support this proposal, I don't think this costs so much money and effort. On Mon, Mar 2, 2020 at 8:34 PM Melchior Aelmans wrote: > Thanks for this very valuable feedback Thiago! Much appreciated! > > Cheers, > Melchior > > On Mon, Mar 2, 2020 at 11:11 AM Thiago da Cruz wrote: > >> Hi all, >> >> Many of you might not know me, but I’m part of RIPE’s software >> engineering team that takes care of RPKI. >> >> I’ve been following this discussion closely and I've noticed some lack of >> clarity about our decision to duplicate our RPKI infrastructure. >> So I think it’s important for us to tell a few things about our approach. >> >> First what we have today in production: >> - TA software (offline box) >> - HSM for the TA (plus backups and spare parts) >> - A few application servers running our RPKI software - I’ll call it >> RPKI-Core >> - Redundant HSMs used by RPKI-Core >> - RRDP publication service (cloud) >> - Some rsync nodes (internal infra) >> >> Something like the diagram below. >> >> For testing environment we have practically the same infra. >> And for public test (localcert) we use ‘soft' keys and no HSMs. >> >> >> About the new AS0 TA, yes, we could simplify our infra. >> One option would be to use ‘soft’ keys all around or use a HSM for TA >> only. >> We could also use third-party software for TA, Core and publication >> service. >> It crossed my mind, for a fraction of a second, to skip AS0 TA instances >> for our internal and/or public test environments. >> >> But I don’t think we should treat it as a "second class citizen". >> If we provide another TA, it’s worthy of receiving as much TLC as our >> production TA; meaning that it would also require the same (or similar) >> process >> around it as our production TA does. That includes keeping track of HSM >> card holders, defining a proper admin and operator quorum, scheduling >> periodical resigning sessions, etc… >> >> I’m not here to advocate against nor in favour of AS0 TA. >> But when discussing our implementation, this was our rationale to >> duplicate the infrastructure. >> And that’s why it would cost us a lot to implement it. >> >> Let me know you need more info about this subject. >> >> Kind regards, >> Thiago da Cruz >> Sr. software engineer - RPKI Team >> RIPE NCC >> >> >> +-+ >> | |+---+ >> |TA (offline) ++ HSM | >> | |+---+ >> +-+ >> >> >> >> >> >> ++ >> >> || >> >>+---> |RRDP publication| >> >>| || >> >>| |(cloud) | >> >>| || >> +---+ +---+ >> | ++ >> | | | | >> Publication| >> |RPKI-Core 1|(...)|RPKI-Core n| >> --> * +> >> | | | | >> | >> +--+-++-+ +--+--+---+-+ >> | ++ >> | || | | | >> | || >> | |+---+ | | | >> | |Rsync publication | >> | || | | ++ >>+---> || >> +-+ +---+ +-+ || >> | (internal infra - x nodes) | >> | | | | || >> || >> | | | +---+ | >> || >> |+-+ | | >> ++ >> || | | | | >> +-++--+ + ++-+--++ >> | HSM 1 | (..) | HSM m | >> +-+ +-+ >> >> >> >> >> >> >> On 27 Feb 2020, at 23:51, George Michaelson wrote: >> >> Anton pointed out I may have both misunderstood and not answered your >> question. >> >> The testbed is a soft TA. In deployment, people will have to move to a >> new (as yet not created) TAL for AS0,
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Hi all, Many of you might not know me, but I’m part of RIPE’s software engineering team that takes care of RPKI. I’ve been following this discussion closely and I've noticed some lack of clarity about our decision to duplicate our RPKI infrastructure. So I think it’s important for us to tell a few things about our approach. First what we have today in production: - TA software (offline box) - HSM for the TA (plus backups and spare parts) - A few application servers running our RPKI software - I’ll call it RPKI-Core - Redundant HSMs used by RPKI-Core - RRDP publication service (cloud) - Some rsync nodes (internal infra) Something like the diagram below. For testing environment we have practically the same infra. And for public test (localcert) we use ‘soft' keys and no HSMs. About the new AS0 TA, yes, we could simplify our infra. One option would be to use ‘soft’ keys all around or use a HSM for TA only. We could also use third-party software for TA, Core and publication service. It crossed my mind, for a fraction of a second, to skip AS0 TA instances for our internal and/or public test environments. But I don’t think we should treat it as a "second class citizen". If we provide another TA, it’s worthy of receiving as much TLC as our production TA; meaning that it would also require the same (or similar) process around it as our production TA does. That includes keeping track of HSM card holders, defining a proper admin and operator quorum, scheduling periodical resigning sessions, etc… I’m not here to advocate against nor in favour of AS0 TA. But when discussing our implementation, this was our rationale to duplicate the infrastructure. And that’s why it would cost us a lot to implement it. Let me know you need more info about this subject. Kind regards, Thiago da Cruz Sr. software engineer - RPKI Team RIPE NCC +-+ | |+---+ |TA (offline) ++ HSM | | |+---+ +-+ ++ || +---> |RRDP publication| | || | |(cloud) | | || +---+ +---+ | ++ | | | | Publication| |RPKI-Core 1|(...)|RPKI-Core n| --> * +> | | | | | +--+-++-+ +--+--+---+-+ | ++ | || | | | | || | |+---+ | | | | |Rsync publication | | || | | ++ +---> || +-+ +---+ +-+ || | (internal infra - x nodes) | | | | | || || | | | +---+ | || |+-+ | | ++ || | | | | +-++--+ + ++-+--++ | HSM 1 | (..) | HSM m | +-+ +-+ > On 27 Feb 2020, at 23:51, George Michaelson wrote: > > Anton pointed out I may have both misunderstood and not answered your > question. > > The testbed is a soft TA. In deployment, people will have to move to a > new (as yet not created) TAL for
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Anton pointed out I may have both misunderstood and not answered your question. The testbed is a soft TA. In deployment, people will have to move to a new (as yet not created) TAL for AS0, as long as it runs independently of the mainline TAL. We intend running a distinct TA for AS0 until we get a clear signal our community wants it integrated. We have stated concerns about the automatic adoption of ASO products worldwide without visible agreement of this activity, a separate TAL turns the activity from opt-out to opt-in. We are duplicating the software signing infrastructure, but with lower costs overall given commonalities. We are still discussing if we can run the offline-TA HSM and the online production key HSM for both activities, or if we need a distinct infrastructure for AS0 and mainline. Duplication overall is not in APNIC's model, we rely on spares and alternate use of the HSM, but production signing systems are single instances. I believe they are capable of some virtualisation or segmentation but that skirts the underlying physical risk/dependency. Sorry for not being clearer before -George On Wed, Feb 26, 2020 at 6:18 PM Carlos Friaças via routing-wg wrote: > > > Hi, > > Any clue if APNIC has duplicated the infrastructure (and cost) as it is > foreseen in the NCC's impact analysis...? > > Carlos > > > > On Wed, 26 Feb 2020, JORDI PALET MARTINEZ via routing-wg wrote: > > > Hi Max, > > > > I think is too early to take a decision, and in fact I don't think we are > > yet in case A. > > > > Consensus is about justified objections. I can see also people in favor and > > I understand, as we usually do in any proposal discussion, that > > non-objection is consent. > > > > The only justification that I can see is from Job about possible cost. > > However, I don't see figures about how much it cost to develop this AS0 + > > how much it cost the operators to use it (if they want) vs developing the > > SLURM + making sure it is secure as RPKI + how much ti cost the operators > > to use it. > > > > And by the way, the AS0 is compatible with the SLURM, so opeartors can > > choose. > > > > Regards, > > Jordi > > @jordipalet > > > > > > > > El 25/2/20 20:30, "routing-wg en nombre de Massimiliano Stucchi" > > escribió: > > > > > >Hi everyone, > > > >On 20/02/2020 15:39, Petrit Hasani wrote: > > > >> As per the RIPE Policy Development Process (PDP), the purpose of this > > four week Review Phase is to continue discussion of the proposal, taking > > the impact analysis into consideration, and to review the full draft RIPE > > Policy Document. > >> > >> At the end of the Review Phase, the Working Group (WG) Chairs will > > determine whether the WG has reached rough consensus. It is therefore > > important to provide your opinion, even if it is simply a restatement of > > your input from the previous phase. > > > >Today, me and the other proposers of this policy change had a meeting to > >discuss the feedback we have been receiving on the list. > > > >We understand that many people find this proposal controversial, and > >many have expressed themselves against it in the past days. > > > >We would like to encourage discussion and provide us with a bit of > >guidance on how the community would like to proceed. At present we have > >identified three ways of progressing: > > > >A) We can try to go ahead with this proposal, although it will be hard > >to get consensus; > > > >B) We can drop the proposal, and leave everything as is; > > > >C) We can change the proposal to a different ask for RIPE NCC. The idea > >could be to ask RIPE NCC to provide a SLURM file (similar to what APNIC > >does), so that single users can decide if they want to feed it to their > >validators. > > > >From what we gathered in the discussions, I think B) could be the most > >sought-after decision, but we would like to propose C) as the way > >forward. It would give the possibility to those who want to implement > >this solution to do it in a lightweight fashion. It would for sure be > >much much cheaper to implement. > > > >In any case, as Job already pointed out, I prepared a simple tool to > >generate a SLURM file using either the Team Cymru bogons list, or > >considering any unassigned space from the NRO delegated stats file. > >RIPE NCC has kindly provided help and patches to improve it. If you > >want to give it a go, you can find it here: > > > >https://github.com/stucchimax/rpki-as0-bogons > > > >Thank you for any suggestion or any discussion around this. > > > >Ciao! > >-- > >Massimiliano Stucchi > >MS16801-RIPE > >Twitter/Telegram: @stucchimax > > > > > > > > > > > > ** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.theipv6company.com > > The IPv6 Company > > > > This electronic message
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Hi Gert, Unfortunately, our PDP doesn't have any definition of consensus (I was miss-recalling a reference to the relevant RFC about "rough consensus") and after re-reading again several times our PDP (RIPE-710). However, in the discussion phase, it is explicitly called for "rough consensus", same in the following phases. What it is clear in any case, is that all the objections must be justified. According to that, I still think that having 10 or 100 (just an example) "no", only count if each one clearly justified (and not refuted by authors or the community), and is still consensus even if you have only a couple of "yes". Regards, Jordi @jordipalet El 26/2/20 18:13, "routing-wg en nombre de Gert Doering" escribió: Hi, On Wed, Feb 26, 2020 at 08:47:31AM +0100, JORDI PALET MARTINEZ via routing-wg wrote: > I can see also people in favor and I understand, as we usually do in any proposal discussion, that non-objection is consent. This assertion is not correct per RIPE PDP rules, except in last call. Gert Doering -- who happens to judge consensus every now and then. -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
In my email the other day, I provided the links to the recent presentation, here is it again: Video: https://www.youtube.com/watch?v=yACx-wJV6FA#t=25m Slides (prop-132 Implementation plan): https://2020.apricot.net/assets/files/APAE432/prop-132-implementation-plan.pdf I recall George mention about low cost, but is only from top of my head. I suggest to look at the video and slides, and probably George can tell something else :-) if they already have more data. I'm guessing that the same infrastructure can handle it and if you increase the infrastructure it can be done in such way that has the advantage to make more resilient the existing one, so it is about the existing RPKI service also. Of course, some development, but I don't think it is that much. Regards, Jordi @jordipalet El 26/2/20 9:18, "routing-wg en nombre de Carlos Friaças via routing-wg" escribió: Hi, Any clue if APNIC has duplicated the infrastructure (and cost) as it is foreseen in the NCC's impact analysis...? Carlos On Wed, 26 Feb 2020, JORDI PALET MARTINEZ via routing-wg wrote: > Hi Max, > > I think is too early to take a decision, and in fact I don't think we are yet in case A. > > Consensus is about justified objections. I can see also people in favor and I understand, as we usually do in any proposal discussion, that non-objection is consent. > > The only justification that I can see is from Job about possible cost. However, I don't see figures about how much it cost to develop this AS0 + how much it cost the operators to use it (if they want) vs developing the SLURM + making sure it is secure as RPKI + how much ti cost the operators to use it. > > And by the way, the AS0 is compatible with the SLURM, so opeartors can choose. > > Regards, > Jordi > @jordipalet > > > > El 25/2/20 20:30, "routing-wg en nombre de Massimiliano Stucchi" escribió: > > >Hi everyone, > >On 20/02/2020 15:39, Petrit Hasani wrote: > >> As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. >> >> At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. > >Today, me and the other proposers of this policy change had a meeting to >discuss the feedback we have been receiving on the list. > >We understand that many people find this proposal controversial, and >many have expressed themselves against it in the past days. > >We would like to encourage discussion and provide us with a bit of >guidance on how the community would like to proceed. At present we have >identified three ways of progressing: > >A) We can try to go ahead with this proposal, although it will be hard >to get consensus; > >B) We can drop the proposal, and leave everything as is; > >C) We can change the proposal to a different ask for RIPE NCC. The idea >could be to ask RIPE NCC to provide a SLURM file (similar to what APNIC >does), so that single users can decide if they want to feed it to their >validators. > >From what we gathered in the discussions, I think B) could be the most >sought-after decision, but we would like to propose C) as the way >forward. It would give the possibility to those who want to implement >this solution to do it in a lightweight fashion. It would for sure be >much much cheaper to implement. > >In any case, as Job already pointed out, I prepared a simple tool to >generate a SLURM file using either the Team Cymru bogons list, or >considering any unassigned space from the NRO delegated stats file. >RIPE NCC has kindly provided help and patches to improve it. If you >want to give it a go, you can find it here: > >https://github.com/stucchimax/rpki-as0-bogons > >Thank you for any suggestion or any discussion around this. > >Ciao! >-- >Massimiliano Stucchi >MS16801-RIPE >Twitter/Telegram: @stucchimax > > > > > > ** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Hi Max, I think is too early to take a decision, and in fact I don't think we are yet in case A. Consensus is about justified objections. I can see also people in favor and I understand, as we usually do in any proposal discussion, that non-objection is consent. The only justification that I can see is from Job about possible cost. However, I don't see figures about how much it cost to develop this AS0 + how much it cost the operators to use it (if they want) vs developing the SLURM + making sure it is secure as RPKI + how much ti cost the operators to use it. And by the way, the AS0 is compatible with the SLURM, so opeartors can choose. Regards, Jordi @jordipalet El 25/2/20 20:30, "routing-wg en nombre de Massimiliano Stucchi" escribió: Hi everyone, On 20/02/2020 15:39, Petrit Hasani wrote: > As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. > > At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. Today, me and the other proposers of this policy change had a meeting to discuss the feedback we have been receiving on the list. We understand that many people find this proposal controversial, and many have expressed themselves against it in the past days. We would like to encourage discussion and provide us with a bit of guidance on how the community would like to proceed. At present we have identified three ways of progressing: A) We can try to go ahead with this proposal, although it will be hard to get consensus; B) We can drop the proposal, and leave everything as is; C) We can change the proposal to a different ask for RIPE NCC. The idea could be to ask RIPE NCC to provide a SLURM file (similar to what APNIC does), so that single users can decide if they want to feed it to their validators. From what we gathered in the discussions, I think B) could be the most sought-after decision, but we would like to propose C) as the way forward. It would give the possibility to those who want to implement this solution to do it in a lightweight fashion. It would for sure be much much cheaper to implement. In any case, as Job already pointed out, I prepared a simple tool to generate a SLURM file using either the Team Cymru bogons list, or considering any unassigned space from the NRO delegated stats file. RIPE NCC has kindly provided help and patches to improve it. If you want to give it a go, you can find it here: https://github.com/stucchimax/rpki-as0-bogons Thank you for any suggestion or any discussion around this. Ciao! -- Massimiliano Stucchi MS16801-RIPE Twitter/Telegram: @stucchimax ** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
If people would like to look at an AS0 state, APNIC's AS0 testbed TAL: https://registry-testbed.apnic.net/as0-test-ta.tal APNIC's AS0 testbed SLURM file: https://registry-testbed.apnic.net/as0-test-slurm.json ~3500 objects, we do not publish one ROA per prefix to avoid a large object set, we do not publish one ROA for all AS0 to avoid a single large object parsing burden. ~65000 prefixes, because of sparse V6 allocation outcomes fragmenting the allocattion spaces.
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Hi everyone, On 20/02/2020 15:39, Petrit Hasani wrote: > As per the RIPE Policy Development Process (PDP), the purpose of this four > week Review Phase is to continue discussion of the proposal, taking the > impact analysis into consideration, and to review the full draft RIPE Policy > Document. > > At the end of the Review Phase, the Working Group (WG) Chairs will determine > whether the WG has reached rough consensus. It is therefore important to > provide your opinion, even if it is simply a restatement of your input from > the previous phase. Today, me and the other proposers of this policy change had a meeting to discuss the feedback we have been receiving on the list. We understand that many people find this proposal controversial, and many have expressed themselves against it in the past days. We would like to encourage discussion and provide us with a bit of guidance on how the community would like to proceed. At present we have identified three ways of progressing: A) We can try to go ahead with this proposal, although it will be hard to get consensus; B) We can drop the proposal, and leave everything as is; C) We can change the proposal to a different ask for RIPE NCC. The idea could be to ask RIPE NCC to provide a SLURM file (similar to what APNIC does), so that single users can decide if they want to feed it to their validators. From what we gathered in the discussions, I think B) could be the most sought-after decision, but we would like to propose C) as the way forward. It would give the possibility to those who want to implement this solution to do it in a lightweight fashion. It would for sure be much much cheaper to implement. In any case, as Job already pointed out, I prepared a simple tool to generate a SLURM file using either the Team Cymru bogons list, or considering any unassigned space from the NRO delegated stats file. RIPE NCC has kindly provided help and patches to improve it. If you want to give it a go, you can find it here: https://github.com/stucchimax/rpki-as0-bogons Thank you for any suggestion or any discussion around this. Ciao! -- Massimiliano Stucchi MS16801-RIPE Twitter/Telegram: @stucchimax signature.asc Description: OpenPGP digital signature
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
> I don't think is objective to say that the proposal as asking the NCC > to "inject" invalids. > > The proposal is providing the information of the invalids (in this > case unallocated/unassigned) by means of RPKI. ok. i was kind of on the fence. but american press has made me oversensitive to fake language such as this; so it threw me over the edge. i do not support the proposal. randy
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
> On Feb 23, 2020, at 8:45 AM, Nick Hilliard wrote: > > JORDI PALET MARTINEZ via routing-wg wrote on 23/02/2020 13:06: >> I don't think is objective to say that the proposal as asking the NCC >> to "inject" invalids. >> The proposal is providing the information of the invalids (in this >> case unallocated/unassigned) by means of RPKI. > > Jordi, > > You're splitting hairs here. The end result is the same. I’m cornered about something like this as we’ve been down this road before with bogon lists, etc and even though it’s well intentioned by smart people(tm), the distributed legacy and cleanup has often taken years to recover. - Jared
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
On 20/02/2020 16:39, Petrit Hasani wrote: I support this proposal. Should have been done a long time ago. Regards, Hank Dear colleagues, Policy proposal 2019-08, "RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space", is now in the Review Phase. The goal of the proposal is to ask the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control. The proposal has been updated following the last round of discussion. Version 2 of the proposal includes a specification for the RIPE NCC to create all AS0 ROAs under a specific Trust Anchor. The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community’s discussion. You can find the proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2019-08 https://www.ripe.net/participate/policies/proposals/2019-08#impact-analysis And the draft documents at: https://www.ripe.net/participate/policies/proposals/2019-08/draft As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and send any comments to before 20 March 2020. Kind regards, -- Petrit Hasani Policy Officer RIPE NCC
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
I don't think is the same, because some people may read it as "the NCC" is forcing us to do some routing thing, which is not the case. El 23/2/20 14:46, "routing-wg en nombre de Nick Hilliard" escribió: JORDI PALET MARTINEZ via routing-wg wrote on 23/02/2020 13:06: > I don't think is objective to say that the proposal as asking the NCC > to "inject" invalids. > > The proposal is providing the information of the invalids (in this > case unallocated/unassigned) by means of RPKI. Jordi, You're splitting hairs here. The end result is the same. Nick ** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
JORDI PALET MARTINEZ via routing-wg wrote on 23/02/2020 13:06: I don't think is objective to say that the proposal as asking the NCC to "inject" invalids. The proposal is providing the information of the invalids (in this case unallocated/unassigned) by means of RPKI. Jordi, You're splitting hairs here. The end result is the same. Nick
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Hi Erik, I don't think is objective to say that the proposal as asking the NCC to "inject" invalids. The proposal is providing the information of the invalids (in this case unallocated/unassigned) by means of RPKI. Furthermore, because this is done via a specific TAL, operators can choose to use it or not. Regards, Jordi @jordipalet El 22/2/20 17:13, "routing-wg en nombre de Erik Bais" escribió: I agree with Job Snijders his remarks on this ML on the topic. I don't think this is a good way forward. Please keep the RIPE NCC away from injecting invalids into the RPKI system. I applaud the authors for their work, but I don't think that the downside, cost projection and possible future scope creep is worth going down this rabbit hole. I oppose this policy. regards, Erik Bais On 20/02/2020, 15:40, "routing-wg on behalf of Petrit Hasani" wrote: Dear colleagues, Policy proposal 2019-08, "RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space", is now in the Review Phase. The goal of the proposal is to ask the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control. The proposal has been updated following the last round of discussion. Version 2 of the proposal includes a specification for the RIPE NCC to create all AS0 ROAs under a specific Trust Anchor. The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community’s discussion. You can find the proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2019-08 https://www.ripe.net/participate/policies/proposals/2019-08#impact-analysis And the draft documents at: https://www.ripe.net/participate/policies/proposals/2019-08/draft As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and send any comments to before 20 March 2020. Kind regards, -- Petrit Hasani Policy Officer RIPE NCC ** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
I agree with Job Snijders his remarks on this ML on the topic. I don't think this is a good way forward. Please keep the RIPE NCC away from injecting invalids into the RPKI system. I applaud the authors for their work, but I don't think that the downside, cost projection and possible future scope creep is worth going down this rabbit hole. I oppose this policy. regards, Erik Bais On 20/02/2020, 15:40, "routing-wg on behalf of Petrit Hasani" wrote: Dear colleagues, Policy proposal 2019-08, "RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space", is now in the Review Phase. The goal of the proposal is to ask the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control. The proposal has been updated following the last round of discussion. Version 2 of the proposal includes a specification for the RIPE NCC to create all AS0 ROAs under a specific Trust Anchor. The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community’s discussion. You can find the proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2019-08 https://www.ripe.net/participate/policies/proposals/2019-08#impact-analysis And the draft documents at: https://www.ripe.net/participate/policies/proposals/2019-08/draft As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and send any comments to before 20 March 2020. Kind regards, -- Petrit Hasani Policy Officer RIPE NCC
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Petrit Hasani wrote on 20/02/2020 14:39: The goal of the proposal is to ask the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control. There is one of proposals which is likely to cause political splash damage. I don't think it should go ahead. Nick
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Hi Job, Petrit, All, (please see inline) On Fri, 21 Feb 2020, Job Snijders wrote: Dear working group, On Thu, Feb 20, 2020 at 04:39:26PM +0200, Petrit Hasani wrote: The goal of the proposal is to ask the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control. The proposal has been updated following the last round of discussion. Version 2 of the proposal includes a specification for the RIPE NCC to create all AS0 ROAs under a specific Trust Anchor. The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community?s discussion. You can find the proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2019-08 https://www.ripe.net/participate/policies/proposals/2019-08#impact-analysis I oppose the policy proposal. I think this is a Bad Idea [tm]. The cost/benefit analysis seems to show that substantial cost is involved to achieve what appears to be a very minor benefit at best, and a great potential for issues down the road. Which issues exactly do you have in mind? Our community could use that money for far more rewarding work. Such as...? It should also be noted that anyone wishing to reject unallocated and unassigned address space can easily do so by converting the data available at https://ftp.ripe.net/pub/stats/ripencc/ into BGP prefix-filters. Yes, it's possible, but not as practical as having it embedded in RPKI -- some may think. There are many ways to suppress the propagation of routing information related to not-yet-assigned space, using the RPKI seems far too big of a hammer. It improves RPKI usage, imho, though. The moment address space is assigned by the RIPE NCC to an end user or LIR, that entity will be able to create RPKI ROAs (if they wish to do so) to glean the very same benefits that AS 0 ROAs for unassigned space would provide up front. But that that point in time it'll be the end users choice to do so. Shifting that moment forward in time doesn't seem to have tangible benefits to me. I do see a significant benefit in marking invalids as "INVALID" instead of "UNKNOWN". Nobody has been able to show me that what operational issues arise from the presence of a handful of unassigned prefixes in the BGP Default-Free Zone. ...and over peerings/IXs. The numer is so low, the prefixes involved don't really seem to pop up on threat radars. Prefixes (especially those which were not legitimately allocated) can come and go, once they have served their purpose I asked the same question in APNIC's policy development community and no answer was provided. Maybe not the best audience to ask about what's on threat radars? Perhaps a different direction can be taken? One of the authors of 2019-08 experimented with generating a SLURM file based on the list of unassigned / unallocated address space, which can easily be incorporated into Origin Validation pipelines. I'm in support of modifying the proposal to not instantiate a new TAL, but rather have the RIPE NCC publish a SLURM [RFC 8416] file. This approach would yield the exact same results at a much lower cost. That would mitigate the "will have to duplicate the entire current RPKI infrastructure..." phrase on the impact analysis, right? :-) I do support 2019-08 as it is, but i can easily support a version 3 with the above suggestion. Cheers, Carlos Kind regards, Job
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
On Fri, Feb 21, 2020 at 03:03:42PM +1100, George Michaelson wrote: > For your information, we are producing a SLURM file as part of our > implementation. This is noted in the slides. > > Purely as an informational and with no intent to otherwise engage in > your policy proposal process, It has been my intention to bring our > implementation report to the RIPE meeting in Berlin and present it in > the routing WG. > > Please let me know if this would be useful or interesting, or is not > helpful. Consider your request noted. Please submit slides! :-) Kind regards, Job
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
For your information, we are producing a SLURM file as part of our implementation. This is noted in the slides. Purely as an informational and with no intent to otherwise engage in your policy proposal process, It has been my intention to bring our implementation report to the RIPE meeting in Berlin and present it in the routing WG. Please let me know if this would be useful or interesting, or is not helpful. -George On Fri, Feb 21, 2020 at 2:54 PM Job Snijders wrote: > > Dear working group, > > On Thu, Feb 20, 2020 at 04:39:26PM +0200, Petrit Hasani wrote: > > The goal of the proposal is to ask the RIPE NCC to create ROAs with > > origin AS0 for all unallocated and unassigned address space under its > > control. > > > > The proposal has been updated following the last round of discussion. > > Version 2 of the proposal includes a specification for the RIPE NCC to > > create all AS0 ROAs under a specific Trust Anchor. > > > > The RIPE NCC has prepared an impact analysis on this latest proposal > > version to support the community’s discussion. > > > > You can find the proposal and impact analysis at: > > https://www.ripe.net/participate/policies/proposals/2019-08 > > https://www.ripe.net/participate/policies/proposals/2019-08#impact-analysis > > I oppose the policy proposal. I think this is a Bad Idea [tm]. > > The cost/benefit analysis seems to show that substantial cost is > involved to achieve what appears to be a very minor benefit at best, and > a great potential for issues down the road. Our community could use that > money for far more rewarding work. > > It should also be noted that anyone wishing to reject unallocated and > unassigned address space can easily do so by converting the data > available at https://ftp.ripe.net/pub/stats/ripencc/ into BGP > prefix-filters. There are many ways to suppress the propagation of > routing information related to not-yet-assigned space, using the RPKI > seems far too big of a hammer. > > The moment address space is assigned by the RIPE NCC to an end user or > LIR, that entity will be able to create RPKI ROAs (if they wish to do > so) to glean the very same benefits that AS 0 ROAs for unassigned space > would provide up front. But that that point in time it'll be the end > users choice to do so. Shifting that moment forward in time doesn't > seem to have tangible benefits to me. > > Nobody has been able to show me that what operational issues arise from > the presence of a handful of unassigned prefixes in the BGP Default-Free > Zone. The numer is so low, the prefixes involved don't really seem to > pop up on threat radars. I asked the same question in APNIC's policy > development community and no answer was provided. > > Perhaps a different direction can be taken? One of the authors of > 2019-08 experimented with generating a SLURM file based on the list of > unassigned / unallocated address space, which can easily be incorporated > into Origin Validation pipelines. I'm in support of modifying the > proposal to not instantiate a new TAL, but rather have the RIPE NCC > publish a SLURM [RFC 8416] file. This approach would yield the exact > same results at a much lower cost. > > Kind regards, > > Job >
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Dear working group, On Thu, Feb 20, 2020 at 04:39:26PM +0200, Petrit Hasani wrote: > The goal of the proposal is to ask the RIPE NCC to create ROAs with > origin AS0 for all unallocated and unassigned address space under its > control. > > The proposal has been updated following the last round of discussion. > Version 2 of the proposal includes a specification for the RIPE NCC to > create all AS0 ROAs under a specific Trust Anchor. > > The RIPE NCC has prepared an impact analysis on this latest proposal > version to support the community’s discussion. > > You can find the proposal and impact analysis at: > https://www.ripe.net/participate/policies/proposals/2019-08 > https://www.ripe.net/participate/policies/proposals/2019-08#impact-analysis I oppose the policy proposal. I think this is a Bad Idea [tm]. The cost/benefit analysis seems to show that substantial cost is involved to achieve what appears to be a very minor benefit at best, and a great potential for issues down the road. Our community could use that money for far more rewarding work. It should also be noted that anyone wishing to reject unallocated and unassigned address space can easily do so by converting the data available at https://ftp.ripe.net/pub/stats/ripencc/ into BGP prefix-filters. There are many ways to suppress the propagation of routing information related to not-yet-assigned space, using the RPKI seems far too big of a hammer. The moment address space is assigned by the RIPE NCC to an end user or LIR, that entity will be able to create RPKI ROAs (if they wish to do so) to glean the very same benefits that AS 0 ROAs for unassigned space would provide up front. But that that point in time it'll be the end users choice to do so. Shifting that moment forward in time doesn't seem to have tangible benefits to me. Nobody has been able to show me that what operational issues arise from the presence of a handful of unassigned prefixes in the BGP Default-Free Zone. The numer is so low, the prefixes involved don't really seem to pop up on threat radars. I asked the same question in APNIC's policy development community and no answer was provided. Perhaps a different direction can be taken? One of the authors of 2019-08 experimented with generating a SLURM file based on the list of unassigned / unallocated address space, which can easily be incorporated into Origin Validation pipelines. I'm in support of modifying the proposal to not instantiate a new TAL, but rather have the RIPE NCC publish a SLURM [RFC 8416] file. This approach would yield the exact same results at a much lower cost. Kind regards, Job
Re: [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Hi Petrit, all, I support the proposal. For the information of the WG, this is the way APNIC is also implementing it. This week in the APNIC meeting, there has been a lot of activity regarding this proposal, which reached consensus there already some time ago, and it is being implemented. If you want to follow those presentations/discussions, here they are: 1) Policy meeting proposal implementation report: Video: https://www.youtube.com/watch?v=yACx-wJV6FA#t=25m Slides (prop-132 Implementation plan): https://2020.apricot.net/assets/files/APAE432/prop-132-implementation-plan.pdf 2) I was asked do a short presentation about the status in other RIRs, so this provides a summary of the situation: Video: https://www.youtube.com/watch?v=NGm5Ha-T_EY#t=1h19m30s Slides: https://2020.apricot.net/assets/files/APAE432/as0-roa-for-bogons-policy-status-in-other-rirs.pdf Regards, Jordi @jordipalet El 21/2/20 1:39, "routing-wg en nombre de Petrit Hasani" escribió: Dear colleagues, Policy proposal 2019-08, "RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space", is now in the Review Phase. The goal of the proposal is to ask the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control. The proposal has been updated following the last round of discussion. Version 2 of the proposal includes a specification for the RIPE NCC to create all AS0 ROAs under a specific Trust Anchor. The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community’s discussion. You can find the proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2019-08 https://www.ripe.net/participate/policies/proposals/2019-08#impact-analysis And the draft documents at: https://www.ripe.net/participate/policies/proposals/2019-08/draft As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and send any comments to before 20 March 2020. Kind regards, -- Petrit Hasani Policy Officer RIPE NCC ** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
[routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Dear colleagues, Policy proposal 2019-08, "RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space", is now in the Review Phase. The goal of the proposal is to ask the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control. The proposal has been updated following the last round of discussion. Version 2 of the proposal includes a specification for the RIPE NCC to create all AS0 ROAs under a specific Trust Anchor. The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community’s discussion. You can find the proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2019-08 https://www.ripe.net/participate/policies/proposals/2019-08#impact-analysis And the draft documents at: https://www.ripe.net/participate/policies/proposals/2019-08/draft As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and send any comments to before 20 March 2020. Kind regards, -- Petrit Hasani Policy Officer RIPE NCC signature.asc Description: Message signed with OpenPGP
