[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 <randy at 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
>