Search RPD Archives
[rpd] RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space AFPUB-2019-GEN-006-DRAFT02
Patrick Okui
pokui at psg.com
Thu Sep 17 09:24:06 UTC 2020
Dear Elvis,
Thanks for speaking up and clarifying this viewpoint. Much as your
concerns
aren’t directly connected to this proposal but to RPKI in general I
think
they’re shared by many and worth addressing. (No I’m not one of the
authors of
this proposal).
To have a mutual understanding (or agreement to disagree) we need to
iron out a
few points. Apologies for the long email that doesn’t discuss the
policy
itself.
1. Allocation of IP addresses (and other resources) is in your words
_”centralised”_. I prefer the word “hierarchal”. I.E IANA
has the global pool
of IP(v4 & v6) addresses. It then hands it out to RIRs like
AFRINIC. LIRS like
ISPs then apply from the RIR. End users either get allocated
address space out
of the LIR pool or can get addresses directly from the RIR and get
those
routed. So, AFRINIC (and other RIRs) are not responsible to
allocate IP
addresses to servers, but you can’t allocate a public IP address
to a server
without somehow following this chain. Kindly confirm if you’re
fine with this
state of affairs.
2. I see you’re using a gmail address and you used the web interface
to compose
your email. To do that your browser used SSL. The system that lets
SSL work is
the X509 certificate system. This is another _”centralised”_ or
hierarchal
system. Your browser or OS has a set of root trust information
(CA’s). These
CAs can create “signatures” (crypto information) that says that
a particular
key XYZ is allowed to secure a domain (e.g gmail.com). They also
can create
signatures that say a key ABC can also create signatures like their
own. In
this case, gmail could chose to go to whoever runs ABC to get their
X509
certificate instead of to any of the roots themselves. Your browser
is able to
follow the chain of trust. Note that x509 aka SSL has methods by
which CAs can
publish crypto information that revokes previously assigned
certificates if
they were allocated in error. Please also confirm if this is
something you’re
fine with.
3. RPKI technically isn’t just for ROA validation. It is just another
public
key infrastructure with *hierarchy* (you prefer the term
centralised). It also
(like x509) requires some sort of root anchor or anchors. These are
what are
installed in each client that wants to verify any of the crypto
information in
the system. This isn’t new, DNSSEC works the same way. Once you
have well
known/established roots each of these systems (DNSSEC, RPKI) have
ways to
delegate authority for some information to the holder of a
different public
key. And this goes down the chain. The decision of who the root
anchors for
RPKI was debated on public lists like these and finally at the NRO
it was
agreed that the easiest and cleanest solution was for all RIRs to
have a root
0/0 anchor. All RPKI validator clients simply have these anchors
configured and
can therefore validate all crypto in the RPKI system.
Kindly confirm if we’re on the same page (at least via understanding)
of these
three long points. Effectively the RPKI system in my opinion is more
trustworthy than the x509 one that secures the SSL you used to write
your
email. If you look at your OS/browser there are quite a number of root
CAs
there that given the choice I personally wouldn’t trust.
Just like DNS, all these systems need hierarchy to operate. It is not
logical
to say you trust x509 (SSL) but not RPKI. Or that you’re fine using
the
internet with its allocation of IP but do not want to secure those
allocations
with a system that follows that same heirachy. Note that we haven’t
even
discussed the fact that publishing ROA information in RPKI is optional
for ISPs
and end users. We’re just discussing the trust hierarchy.
On 17 Sep 2020, at 9:26 EAT, Ibeanusi Elvis wrote:
> Dear all,
>
> The AFRINIC as an organization specifically focuses on the
> registration database and thereby having knowledge of where the prefix
> belongs to and AFRINIC should just focus on this role and should not
> engage in authenticating or the authorization of various services. If
> such rights are given to any organization, they have the right to
> assign prefixes to servers hence, having control of the routing
> database at which a technical or human error will lead to an immense
> catastrophe to the internet society.
> This control is basically the specific definition of centralization.
> This centralization is the major reason why most providers do not
> trust the Resource Public Key Infrastructure (RPKI). I am still in
> opposition to this policy proposal.
>
> Elvis.
>
> On Thu, Sep 17, 2020 at 3:01 PM Darwin Costa <dc at darwincosta.com>
> wrote:
>
>> Cmon folks….!
>>
>> @Elvis, I really don’t see your point here and also don’t really
>> understand why are you opposing against this proposal.
>>
>> As mentioned further on the thread - RPKI won’t change Afrnic´s
>> role at
>> all…. Instead this proposal will certainly contribute to a more
>> secure
>> routing advertisement.
>>
>> As such, other RIR´s have successfully implemented this in order to
>> protect our garden so called “The Internet”.
>>
>> Darwin-.
>>
>>
>>
>> On 17 Sep 2020, at 05:42, Fernando Frediani <fhfrediani at gmail.com>
>> wrote:
>>
>> I think there is a serious issue by some people totally
>> misunderstanding
>> what RPKI actually is.
>>
>> Some arguments saying something like 'Afrinic will centralize control
>> of
>> the internet and should not have such power' don't have relation to
>> what
>> what this proposal intends and the reasons to oppose it are not tied
>> to
>> real possible problems pointed.
>>
>> This proposal only follows what have been done in APNIC and LACNIC
>> and is
>> a natural move to make an internet more secure and avoid
>> organizations to
>> use space that is not assigned to anyone else.
>> Therefore I support this proposal.
>>
>> Fernando
>> On 16/09/2020 20:42, Noah wrote:
>>
>>
>> On Thu, Sep 17, 2020 at 2:30 AM Ibeanusi Elvis
>> <ibeanusielvis at gmail.com>
>> wrote:
>>
>>>
>>> I am strongly in opposition to this RPKI ROA proposal,
>>>
>>
>> You oppose yet....
>>
>>
>>> issuing an AS0 for AFRINIC address space
>>>
>>
>> You must be clear on which AFRINIC address space rather than
>> presenting a
>> rather vague statement.
>>
>> The proposal is very clear and explicit and the AFRINIC space in
>> question
>> is that which has not yet been allocated or assigned to any entity or
>> resource member.
>>
>> I will quote for you section 2.0 of the proposal as written below;
>>
>> *2.0 Summary of how this proposal addresses the problem*
>>
>> This proposal instructs AFRINIC to create ROAs for all *unallocated
>> and
>> unassigned address space under its control.* This will enable
>> networks
>> performing RPKI-based BGP Origin Validation to easily reject all the
>> bogon
>> announcements covering resources managed by AFRINIC.
>>
>> So what are you talking about?
>>
>> Noah
>>
>>
>> _______________________________________________
>> RPD mailing
>> listRPD at afrinic.nethttps://lists.afrinic.net/mailman/listinfo/rpd
>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.afrinic.net%2Fmailman%2Flistinfo%2Frpd&data=02%7C01%7C%7Ca48324a7026842948aff08d85abbfbd8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637359110720490840&sdata=mOjgUTIarKfPnsD2h0TtixnR51E4wzIwqoo6rONHW%2FI%3D&reserved=0>
>>
>> _______________________________________________
>> RPD mailing list
>> RPD at afrinic.net
>>
>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.afrinic.net%2Fmailman%2Flistinfo%2Frpd&data=02%7C01%7C%7Ca48324a7026842948aff08d85abbfbd8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637359110720510827&sdata=jlnsXCK7dATX4Jcg48%2BhurUnj1E5umTa2RZq7IMsb%2Fs%3D&reserved=0
>>
>>
>> _______________________________________________
>> RPD mailing list
>> RPD at afrinic.net
>> https://lists.afrinic.net/mailman/listinfo/rpd
>>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
--
patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20200917/63c1c6e8/attachment-0001.html>
More information about the RPD
mailing list