[rpd] RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space AFPUB-2019-GEN-006-DRAFT02

[JORDI PALET MARTINEZ]

Hi Ben,

Please see below, in-line as [Jordi]

Regards,
Jordi
@jordipalet
 
 

El 17/9/20 11:15, "Ben Maddison via RPD" <rpd at afrinic.net> escribió:

    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.

[Jordi] I don't think that's so problematic. If you followed Madhvi explanation, the mistake will come from the whois, so this may affect already other non-RIR managed databases, etc., and then will be propagated to the AS0 TAL, which will take 5 minutes to be re-generated but then, as Mark explained, it takes hours to reach the ISPs systems. You don't think that the time to detect the error will be faster, if correctly implemented, than the time to update the ISPs ? Should not AFRINIC (as already the staff indicated in the impact assessment) to ensure that everything is correct with a double check, even if instead of 5 minutes takes longer? Note that the 5 minutes come from the operational decision from APNIC, they already implemented this. Do you think they did wrong? Also, before this becomes implemented in AFRINIC, LACNIC is already implementing it as well. You don't think that there are 3 sets of "RIR-staff" looking at the same thing, from different perspectives, so to avoid anything wrong?

[Jordi] Also if you look at the APNIC videos (see the links in the slides) you will see that big networks are already using the TAL for the AS0 of APNIC. For me it is obvious that we will have several months of verification, before AFRINIC implementation, so longer time to make sure that nothing is done in a "broken" way.

[Jordi] Last, but not least, having the AS0 in a separate TAL becomes an opt-in service, so if any ISP is not "sure" he can just not use it and even if you're using it, and an error is created, you just need to temporarily disable that TAL in your systems, problem gone!.

    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!

[Jordi] I will say it greatly depends on many operational details, so purely case by case bases ...

    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.

[Jordi] 1 and 3 are already in the proposal, the staff already confirmed their interpretation on that.

[Jordi] 2. This doesn't make sense in my opinion, otherwise, we are contradicting the RSA and the PDP. There is a clear example if you don’t pay the bills, AFRINIC will try to contact you by all means, recover the situation, wait some time, etc., etc (this is also what we try improve with the policy compliance dashboard). But if all that fails, the RSA already allows AFRINIC to recover the resources, so obviously a “bad guy” will not authorize AFRINIC to publish in the AS0 … What I’m missing or misunderstanding? Can the staff confirm that this is right, so is not just my "words" on the understanding of the RSA?



    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

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