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" <job@sobornost.net> 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.
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
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
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
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 <randy@psg.com> 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
but, ggm, you did not actualy respond to the message to which you were replying.
would this duplication of infrastructure actually be needed or useful? the american idiom is "making a mountain out of a molehill"
randy
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
On 2020-03-04 08:23, Carlos Friaças via routing-wg wrote:
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... :-(
I'm more optimistic. If SLURM is the chosen path, then support for it only need to materialise in RPKI software -- which I'm pretty sure it will, since maintainers of said software know what they are doing and they are generally responsive to user needs. Robert
Hi Robert, All, My main issue was about every netadmin (i.e. each ASN) having to do something alongside RPKI. If the info about unallocated/unassigned can be kicked-in at the RPKI software level, that will make life easier for each ASN-admin -- i.e. only need to worry about running RPKI and fine tune it... Thanks for raising my optimism! Cheers, Carlos On Wed, 4 Mar 2020, Robert Kisteleki wrote:
On 2020-03-04 08:23, Carlos Friaças via routing-wg wrote:
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... :-(
I'm more optimistic. If SLURM is the chosen path, then support for it only need to materialise in RPKI software -- which I'm pretty sure it will, since maintainers of said software know what they are doing and they are generally responsive to user needs.
Robert
while i am tempted toward the slurm approach, i wonder what authenticates the slurm file(s)? randy
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
On Wed, Mar 04, 2020 at 11:36:55AM +0000, 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
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
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
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" <routing-wg-bounces@ripe.net en nombre de nick@foobar.org> 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.
If I got feedback in my community they don't feel this needs HSM backing, I can avoid the problem.
That sounds logical. It leads me to the question: what's the threat model for protecting the "RIR AS0 key"? In other words what happens if an attacker can sign stuff (CAs, ROAs, ...) of their choosing with it [1]? Depending on the severity of scenarios in the answer [2], the use of HSM for the TA may or may not make a difference. Robert [1] note that in order to "sign stuff of their choosing" does not mean they need to get the key (which is of course harder when using an HSM). They only need to convince the system to sign the attacker's blobs, which is a very different problem. [2] random ideas: * does the AS0 TA cover 0/0 or only the unallocated space? * If someone makes a non-AS0 ROA under this TA, how does that interact with a ROA from under a different TA? * does this whole thing matter if some address space (ie. from other RIRs) is not covered by an AS0 TA anyway?
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
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
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
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
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" <routing-wg-bounces@ripe.net en nombre de job@instituut.net> 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.
participants (8)
-
Carlos Friaças -
George Michaelson -
Job Snijders -
Job Snijders -
JORDI PALET MARTINEZ -
Nick Hilliard -
Randy Bush -
Robert Kisteleki