This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/routing-wg@ripe.net/
[routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
- Previous message (by thread): [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
- Next message (by thread): [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Carlos Friaças
cfriacas at fccn.pt
Wed Mar 4 08:23:08 CET 2020
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 >
- Previous message (by thread): [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
- Next message (by thread): [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]