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