[routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)

Thanks for this very valuable feedback Thiago! Much appreciated!

Cheers,
Melchior

On Mon, Mar 2, 2020 at 11:11 AM Thiago da Cruz <tdacruz at ripe.net> 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 <ggm at algebras.org> 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, 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
> <routing-wg at ripe.net> 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" <
> routing-wg-bounces at ripe.net en nombre de max at stucchi.ch> 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.
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/routing-wg/attachments/20200302/8870d962/attachment-0001.html>