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

[JORDI PALET MARTINEZ]

Hi Topsy,

 

All those points are in the proposal. I’m wondering if we are reading the same text.

 

https://www.afrinic.net/policy/proposals/2019-ipv4-002-d4#proposal

 

The staff also analyzed that, and you can see in their impact assessment that they have no doubts about any of your points.

 

https://www.afrinic.net/policy/proposals/2019-ipv4-002-d4#impact

 

 

So can you clarify what are you missing, or something else so I can really understand your points?

 

Regards,

Jordi

@jordipalet

 

 

 

El 17/9/20 12:43, "Topsy Bello via RPD" <rpd at afrinic.net> escribió:

 

IPV4 inter RIR Resource Transfer (comprehensive scope)  

 

we need to answer the following questions and critically weigh the outcome

 

 

1 details regarding the transfer? 

 

2.what are the criteria? 

 

3. does the transfer follow AFRINIC or the receiving parties policy?

 

for me its a BIG NO to this policy

 

 

cheers

 

On Thursday, September 17, 2020, 11:25:33 AM GMT+1, Emem William <dwizard65 at gmail.com> wrote: 

 

 

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

_______________________________________________
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 



**********************************************
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: <https://lists.afrinic.net/pipermail/rpd/attachments/20200917/3891e6ac/attachment-0001.html>