Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] IPv4 Inter RIR Resource Transfer (Comprehensive Scope)

Emem William dwizard65 at gmail.com
Thu Sep 17 10:24:12 UTC 2020


Dear all,

In my opinion, this new policy proposal is not necessary because the
Resource Transfer Policy would already support a bi-directional inter-RIR
Transfer Policy which is capable of encouraging growth and smooth business
operations within in the region.

Cheers
Emem William

On Thu, Sep 17, 2020, 11:17 Ahile shagba francis <ahilefranc at gmail.com>
wrote:


> Lets look at it from another point,

> If it is the other region’s policy to be applied when the resources are

> transferred from that region, it is then glaring that this could cause many

> confusions.

> We don't need to support such.

> Let's be guided.

>

>

>

> On Thu, Sep 17, 2020, 10:25 AM <rpd-request at afrinic.net> wrote:

>

>> Send RPD mailing list submissions to

>> rpd at afrinic.net

>>

>> To subscribe or unsubscribe via the World Wide Web, visit

>> https://lists.afrinic.net/mailman/listinfo/rpd

>> or, via email, send a message with subject or body 'help' to

>> rpd-request at afrinic.net

>>

>> You can reach the person managing the list at

>> rpd-owner at afrinic.net

>>

>> When replying, please edit your Subject line so it is more specific

>> than "Re: Contents of RPD digest..."

>>

>>

>> Today's Topics:

>>

>> 1. Re: RPKI ROAs for Unallocated and Unassigned AFRINIC Address

>> Space AFPUB-2019-GEN-006-DRAFT02 (Ben Maddison)

>> 2. Re: RPKI ROAs for Unallocated and Unassigned AFRINIC Address

>> Space AFPUB-2019-GEN-006-DRAFT02 (Patrick Okui)

>>

>>

>> ----------------------------------------------------------------------

>>

>> Message: 1

>> Date: Thu, 17 Sep 2020 11:08:16 +0200

>> From: Ben Maddison <benm at workonline.africa>

>> To: Mark Elkins <mje at posix.co.za>

>> Cc: Marius Andioc via RPD <rpd at afrinic.net>

>> Subject: Re: [rpd] RPKI ROAs for Unallocated and Unassigned AFRINIC

>> Address Space AFPUB-2019-GEN-006-DRAFT02

>> Message-ID: <20200917090816.nwkt44vwwjaun6wo at benm-laptop>

>> Content-Type: text/plain; charset="utf-8"

>>

>> Hi all,

>>

>> I am currently undecided on this policy.

>> As others have pointed out, the objections to the proposal on the basis

>> of centralization of control are bogus: the current policy does not add

>> any additional control over the routing system beyond that which AFRINIC

>> already has as the result of RPKI origin validation deployment today.

>>

>> I agree with the fundamental basis of the proposal that:

>> a) it is generally undesirable to route traffic for bogon destinations;

>> and

>> b) the RPKI is the best fit we have to securely communicate what is and

>> isn't a bogon to relying parties in order to implement the necessary

>> routing policy.

>>

>> However, it is also the case that the consequences (in terms of service

>> availability for end users) of a de-registration would be substantially

>> greater if the de-registration is accompanied by the issuance of an AS0

>> ROA for that address space.

>>

>> This is true for the following reasons:

>> - Non-RIR managed IRR databases exist that allow the creation of

>> route(6) objects that are not covered by an RIR allocation

>> - Many networks do not filter by prefix based on IRR data at all

>> - Those that do generally do not filter their transits by prefix

>> - Transit-free networks generally do not filter their peers (or at least

>> their transit-free peers) by prefix

>>

>> Thus, today, a de-registration probably results in a partial outage that

>> can be worked-around, rather than a near-total outage that cannot.

>> This is either a feature or a bug in the policy, depending on your point

>> of view regarding a specific de-registration case!

>>

>> I would suggest the following modifications, in order to alleviate some

>> of the risks inherent in the current draft:

>> 1. The automatic creation of AS0 ROAs should be limited to space that

>> has never been allocated by an RIR or part of a legacy allocation.

>> 2. AFRINIC should require the explicit consent of the previous holder

>> to issue AS0 ROAs in respect of re-claimed, returned, etc, space.

>> 3. Any ROAs issued under this policy should be issued and published in

>> a way that makes it operationally easy for an relying party to

>> ignore them (probably by issuing under a separate TA)

>>

>> With the above amendments I would be inclined to support the proposal.

>>

>> Cheers,

>>

>> Ben

>>

>> On 09/17, Mark Elkins wrote:

>> > I support the RPKI ROA policy as written. I understand the technical

>> aspects

>> > of the policy. I have a feeling that those objecting may not completely

>> > understand the technical aspects which is why they are objecting.

>> >

>> > AFRINIC's job is to properly document the resources they have been

>> provided

>> > by ICANN/IANA and this is simply part of the job. When new resources are

>> > provided to AFRINIC, they label it as such (AS0, etc). When it is then

>> > allocated/assigned to a member, the AS0 RPKI is removed. All this means

>> is

>> > that the unallocated/unassigned resources that are with AFRINIC can be

>> > (optionally) identified as such and thus can not be easily misused by

>> bad

>> > actors. This also means that when they are allocated/assigned to

>> members,

>> > they are less lightly to have been made "dirty".

>> >

>> > On 2020/09/17 08:26, 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

>> > > <mailto: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

>> > > > <mailto: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 <mailto: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 list

>> > > > > RPD at afrinic.net <mailto:RPD at afrinic.net>

>> > > > > https://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 <mailto: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 <mailto: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

>> > --

>> >

>> > Mark James ELKINS? -? Posix Systems - (South) Africa

>> > mje at posix.co.za?????? Tel: +27.826010496 <tel:+27826010496>

>> > For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za

>> >

>> > Posix SystemsVCARD for MJ Elkins

>> >

>>

>> > _______________________________________________

>> > RPD mailing list

>> > RPD at afrinic.net

>> > https://lists.afrinic.net/mailman/listinfo/rpd

>>

>> -------------- next part --------------

>> A non-text attachment was scrubbed...

>> Name: signature.asc

>> Type: application/pgp-signature

>> Size: 833 bytes

>> Desc: not available

>> URL: <

>> https://lists.afrinic.net/pipermail/rpd/attachments/20200917/77e69095/attachment-0001.sig

>> >

>>

>> ------------------------------

>>

>> Message: 2

>> Date: Thu, 17 Sep 2020 12:24:06 +0300

>> From: "Patrick Okui" <pokui at psg.com>

>> To: "Ibeanusi Elvis" <ibeanusielvis at gmail.com>

>> Cc: Marius Andioc via RPD <rpd at afrinic.net>

>> Subject: Re: [rpd] RPKI ROAs for Unallocated and Unassigned AFRINIC

>> Address Space AFPUB-2019-GEN-006-DRAFT02

>> Message-ID: <91E9F948-7128-4E24-903B-2033484E1DC3 at psg.com>

>> Content-Type: text/plain; charset="utf-8"; Format="flowed"

>>

>> 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.html

>> >

>>

>> ------------------------------

>>

>> Subject: Digest Footer

>>

>> _______________________________________________

>> RPD mailing list

>> RPD at afrinic.net

>> https://lists.afrinic.net/mailman/listinfo/rpd

>>

>>

>> ------------------------------

>>

>> End of RPD Digest, Vol 168, Issue 82

>> ************************************

>>

> _______________________________________________

> RPD mailing list

> RPD at afrinic.net

> https://lists.afrinic.net/mailman/listinfo/rpd

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20200917/f867e8ec/attachment-0001.html>


More information about the RPD mailing list