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

[rpd] RPD Digest, Vol 168, Issue 82

Stephen Oladepo stephenoladepo24 at gmail.com
Thu Sep 17 13:25:19 UTC 2020


Hi. Pls I want to stop receiving this mail.

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

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

>

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


More information about the RPD mailing list