Dear Xiaoyu (by lack of a signature in your messages, I don’t know who you are),
First, I think you need to familiarize yourself with the concept of aggregation in BGP and the RIPE policies for Provider
Aggregatable address space and why we want to do that.
I think both ideas are stupid.
The way it works now is that there is always either a PA allocation to an LIR or a direct PI allocation to an individual that should have a sponsoring LIR that can make changes on his behalf, or give it’s sponsoring customers access to the hosted RPKI system:
https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/resource-certification-rpki-for-provider-independent-end-users/
RIPE already has the possibility to create ROAs for PI or LEGACY address space, and even lets the assignment holder manage the ROAs.
But it is the sponsoring LIR that can give you that authority by giving you your own maintainer object in the RIPE database to manage your PI holder organisation and ROAs.
If your current sponsor doesn’t give you that authority, choose a different sponsoring LIR:
https://www.ripe.net/manage-ips-and-asns/resource-management/number-resources/independent-resources/information-on-independent-resources-for-end-users/
I can imagine that sponsoring LIRs are reluctant to give that authorisation, because most of the time the address holders of PI address space have no clue how the RIPE database nor its policies or RPKI work, and that is a security risk by itself. This email
thread is a great example that even here on the MANRS mailing list people don’t understand how the registry system works.
I have the experience, maintaining IRR data and RPKI ROAs for many PI customers, that in the end I always need to help them when changes are necessary. Mostly after a number of years and their sysadmin that had some clue left the company many moons ago because
he was underpaid.
Give me a prefix, and I will tell you who you need to go to to maintain your RPKI ROA.
I also think it will be a very bad idea to let MANRS or any other organisation like RADB handle RPKI trust anchors. I will certainly not use those trust anchors in my validator as they will be untrustworthy. There is no guarantee the ROAs are created by the
legitimate IP holders. Only the RIRs can verify the ROAs are created by the legitimate IP holder since they maintain the allocations to those holders. This is the whole concept of RPKI.
In that same sense, I do not trust any RADB IRR data, as anyone can just create objects in that database. We require address holders to create route objects in an RIR IRR if we need to route their traffic, the non-RIR IRRs are too much a mess to be reliable
because of these unauthorised objects. We want to get rid of those IRRs, so people don’t get these stupid insecure ideas: https://ripe88.ripe.net/wp-content/uploads/presentations/87-RIPE88_RS_Proposal_BCP_IRRDBs_1.2.pdf.
>
/40 can be allocated to many /48s
No they cannot. That would be a BGP nightmare and all routers would die (https://www.youtube.com/watch?v=_y36fG2Oba0).
They can be “-ASSIGNED-” to many /48s. Please familiarize yourself with
what that means and why.
Kind regards,
Antoin Verschuren
Senior Manager Network Security IETF REGEXT Co-chair
Liberty Global Technology Services B.V.
Boeing Avenue 53
1119 PE Schiphol-Rijk
The Netherlands
From: Manrs-community <manrs-community-bounces@elists.manrs.org>
On Behalf Of xiaoyu.net via Manrs-community
Sent: Thursday 14 November 2024 06:21
To: manrs-community@elists.manrs.org
Subject: Re: [manrs-community] Implementing Decentralized RPKI with Blockchain Technology
I don't know why it's so hard for you to understand this. /40 can be allocated to many /48s. Make full use of the IP space. Any situation is possible. Let everyone
manage their own information. Why make each LIR do it? Since you are allowed to manage ROA yourself, why not allow you to manage RPKI yourself?
What I mean is to popularize security. For example, SSL certificates were sold at high prices before, but now almost everyone can use SSL certificates for free
and they can be automated. Does RPKI have to be manually operated by LIR every time?
This is like you authorize someone to use your house. You must give the key to the guest so that they can manage the security themselves, right? Do you have
to ask the landlord to open the door every time? Is this necessary?
From: Gert Doering <gert@space.net>
To: "xiaoyu.net" <yon@xiaoyu.net>
Cc: manrs-community@elists.manrs.org
Date: Wed, 13 Nov 2024 21:10:03 +0100
Subject: Re: [manrs-community] Implementing Decentralized RPKI with Blockchain Technology
Hi,
On Thu, Nov 14, 2024 at 12:50:54AM +0800, xiaoyu.net via Manrs-community wrote:
> I don't agree with this view. For example, a /40 ipv6 address block is
> assigned to a person who has no connection with the LIR. Submitting RPKI
> settings to the LIR is difficult and impossible to keep up to date. Because
> updating and setting up RPKI for a large number of IPv6 prefixes to LIR is a
> very heavy task. What I mean is that the person who actually manages the use
> of the IP prefix should be allowed to set up RPKI himself in RIPE.
A /40 IPv6 can be assigned by the RIPE NCC, or by an ISP (acting for
the LIR). So the chain of assignment is clear, and if the ISP is permitting
independent BGP announcement of said /40, they can do the RPKI ROA just
fine ("two clicks in the RIPE LIR portal") - and if not, it's their
decision to not allow that.
If the /40 is coming from the RIPE NCC, the NCC will do RPKI.
Normally the ROA setup is a one-time thing - if you have "a large number
of prefixes" and RPKI changes all the time (making it a "very heavy task"),
it sounds as if you're mostly holding it wrong.
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla,
Karin Schuler, Sebastian Cler
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
************************************
Our Mail Server Support IPv6 & IPv4
************************************