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 <[email protected]> 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 >
