Search RPD Archives
[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