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

[Patrick Okui]

Hi Lamiaa,

Firstly thanks for giving actual examples of where you see this as 
interference with routing. It makes it easier to see your point of view.

Jordi and Noah have already responded to this and partially addressed 
your concerns.

There are only two cases where AS0 entries will be made and I think the 
idea is AFRINIC can publish this in a different TAL.

1. Noah has mentioned this. But this is for address space that is *not* 
allocated yet to anyone. In this scenario there is no member who can 
create RPKI ROA entries for this nor any route(6): objects. Technically 
this space still “belongs” to AFRINIC. Basically say IANA allocates 
a new IPv6 subnet to AFRINIC and they create an AS0 entry for it. I 
think many people have mentioned that this part can even be automated.

2. Address space is reclaimed e.g from a member not in good standing. 
This is inline with the RSA etc and goes through a verification process 
(not special to RPKI nor whois nor reverse DNS). At this point, whois 
objects (e.g inetnum:) are also removed and therefore any route: objects 
that depend on them will disappear. Similarly reverse DNS dies. I 
believe the discussions around this were concluded but someone can 
kindly refresh my understanding. So, in this case, AFRINIC will be 
modifying potentially routing impacting entries as they should and 
already can.

Note that if by some weird error AFRINIC creates or removes wrong whois 
entries it will impact your routing. But this is not very different as 
if IANA somehow publishes the wrong prefix allocated to the wrong RIR.

So your two points specifically 1. AFRINIC doesn’t have actions they 
currently do that can affect routing and 2. The current operations do 
not have situations where some theoretical mistake can not affect 
existing members routing are not true. Any potential mistakes with your 
prefix showing up in AS0 would be handled same way potential errors with 
your inetnum: (and therefore route:) objects disappearing. By contacting 
member services. I hope you are not suggesting that if AFRINIC finally 
reclaim address space they should not remove whois objects because they 
theoretically may make a mistake.

Kindly advise where I’m missing something.

On 30 Sep 2020, at 21:57 EAT, Lamiaa Chnayti wrote:


> Hey Jordi,

>

> The very fundamental objection to this policy, is that RIR is about 

> registration polices, and not routing policies.

>

> This is a policy that potentially asks AFRINIC to proactively 

> interfere with routing, which is out of scope of RIR’s mandate.

>

> Before this policy, all route object of AFRINIC or RPKI provided by 

> AFRINIC, are created by its members, so those operate the networks, 

> AFRINIC does not proactively create route object or change RPKI for 

> any of resource it manages registration with.

>

> And this policy changes that, and this is not what AFRINIC should or 

> is meant to do.

>

> And of course, when you ask Afrinic to interfere with routing, a 

> mistake in registration does not immediately impact network operation, 

> but a mistake in routing, it does, so others have raised concern over 

> potential mistake of Afrinic or Afrinic staff, in which in the past 

> there was serious mistakes made by staff members, and potential legal 

> consequence of that is another major objection to this policy.

>

> Please read and consider, and don’t act like everybody including 

> chairs are fools and you are the only smart guy in the room, let’s 

> discuss this matter in a constructive way

>

> Regards,

>

> Lamiaa

>

> Le mer. 30 sept. 2020 à 15:43, JORDI PALET MARTINEZ via RPD 

> <rpd at afrinic.net>

> a écrit :

>

>> Hi AK, Moses, all,

>>

>>

>>

>> I will like you to reconsider your decision on this proposal, 

>> following

>> CPM 3.5, on the grounds of my responses below, which have already 

>> been

>> provided thru previous discussions and I don’t think any of those 

>> are

>> valid-objections to the proposal.

>>

>>

>>

>> See my points below, in-line.

>>

>>

>>

>>

>>

>> Regards,

>>

>> Jordi

>>

>> @jordipalet

>>

>>

>>

>> 7.       RPKI ROAs for Unallocated and Unassigned AFRINIC Address 

>> Space

>>

>> The 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. However, there 

>> are

>> many oppositions such as:

>>

>> a.                      Allowing resource holders to create AS0/ ROA 

>> will

>> lead to an increase of even more invalid prefixes in the routing 

>> table.

>>

>>

>>

>> This shows a lack of understanding of RPKI and the relevant RFCs. 

>> Resource

>> holders **ALREADY CAN and DO** that (example IXPs), in fact they do. 

>> This

>> has been explained in my presentation. The proposal is just adding 

>> clarity

>> on this point, not changing anything.

>>

>>

>>

>> b.                      Revocation time of AS0 state, and the time 

>> for

>> new allocation doesn’t match.

>>

>>

>>

>> This is not true, again a misunderstanding about how RPKI works. 

>> Several

>> members discussed this in the list. If you get resources, normally 

>> you

>> don’t publish them in minutes, so hours, or even days is perfectly 

>> valid.

>> In addition to that, it can be improved thru implementation, as I 

>> already

>> explained. The staff could tentatively release from the AS0 the 

>> resources

>> that they plan to allocate (pending on final documentation, RSA 

>> signature,

>> or review with the member, etc.).

>>

>>

>>

>> c.                       Other RIRs don’t have a similar the policy

>> therefore, it can not be effective

>>

>>

>>

>> All the policies have different discussions in different RIRs at 

>> different

>> times. This policy is already available in APNIC and LACNIC. There 

>> are

>> policies in AFRINIC which aren’t in other RIRs. Does that make them 

>> invalid

>> (or in other words, this is an invalid objection – is good that all 

>> RIRs do

>> the same, but is not always that the case, or not at the same time).

>>

>>

>>

>> d.                      This will become a uniform policy if it is 

>> not

>> globally implemented, which causes additional stress.

>>

>>

>>

>> Absolutely not, the way we suggest the staff, and they confirmed, 

>> with an

>> independent TAL protects **as expected by the proposal** the 

>> resources of

>> the RIR implementing it, not creating **any issue** in what is done 

>> in

>> other RIRs to any operator.

>>

>>

>>

>> e.                  Validity period:   if members decide to implement 

>> it,

>> is it not better to recover the space if it is kept unused for too 

>> long?

>>

>>

>>

>> This doesn’t make sense, at least not as worded. This is not about

>> recovering space, no relation. It is the unused space hold by 

>> AFRINIC.

>>

>>

>>

>> e.                      How do we revoke the ROA? How long does it 

>> take

>> to revoke it (chain/ refreshing )?

>>

>>

>>

>> This is the same as b above, right? It doesn’t matter in practice, 

>> if it

>> takes minutes or hours or even days.

>>

>>

>>

>> f.                        What happens if AFRINIC accidentally issues 

>> a

>> ROA for an address in error?

>>

>>

>>

>> Exactly the same if the existing RPKI fails, and that’s why there 

>> are

>> monitoring systems in place and caches, etc. This proposal doesn't 

>> change

>> that.

>>

>>

>>

>> g.                      It also might affect the neighbours and 

>> involves

>> monitoring of unallocated spaces.

>>

>>

>>

>> What is the meaning of neighbours here? Yes, the same monitoring that 

>> **right

>> now** should be done by AFRINIC. This proposal ensures that it is

>> improved so hijacking of unused space is less prone to occur, that 

>> the

>> purpose of the proposal and RPKI, increase the routing security.

>>

>>

>>

>> h.                      Possibility of it being used against a member 

>> who

>> is yet to pay dues.

>>

>> AFRINIC has the obligation to avoid members not paying to stop using 

>> the

>> resources, so they are available to other members. Even if we don’t 

>> have

>> this proposal, AFRINIC could, following the bylaws and RSA, do 

>> whatever

>> actions, including technical ones, to make sure that they are not 

>> used.

>>

>>

>>

>> Suggestions were made to improve the policy such as

>>

>> a)                  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.

>>

>>

>>

>> This doesn’t make any sense and has not been considered at all in 

>> other

>> RIRs discussions. That will mean that even if a member return the 

>> space,

>> and stop replying to AFRINIC, the space will never come to the AS0 

>> ROAs.

>> This is related also to the next point.

>>

>>

>>

>> b)                  AFRINIC should require the explicit consent of 

>> the

>> previous holder to issue AS0 ROAs in respect of re-claimed, returned, 

>> etc,

>> space.

>>

>>

>>

>> This doesn’t make any sense and has not been considered at all in 

>> other

>> RIRs discussions. If a member is not following the established legal

>> bindings, not just AFRINIC, but **any** organization, has the 

>> obligation,

>> to ensure that the member is not cheating the other members and take 

>> any

>> actions they can to fullfill the recovery or whatever is needed. The

>> proposal doesn’t state if AFRINIC should take some intermediate 

>> steps in

>> cases of litigation, disagreements, etc. however, the legal documents

>> already state that they should try to remediate the situation before 

>> the

>> recovery, so it is clearly part of the existing process and will not 

>> only

>> affect this proposal but all the CPM. A member can just disappear (a

>> bankruptcy), so if this is not done, the resources could never be

>> recovered, while the legal documents, already state that!

>>

>>

>>

>> c)                   Any ROAs issued under this policy should be 

>> issued

>> and published in a way that makes it operationally easy for a relying 

>> party

>> to ignore them (probably by issuing under a separate TA).

>>

>>

>>

>> This is already explicit in the proposal and confirmed by the staff.

>> Nevertheless, it is an operational decision, and could be changed 

>> over the

>> time.

>>

>>

>>

>> d)                  The proposal should include the clause “as used 

>> in

>> APNIC as to dues not paid on time.”

>>

>> Can you please point to the relevant presentation? I’ve followed, 

>> and

>> reviewer all the APNIC work on this (I participated in all that) and 

>> I

>> can’t find what you mean.

>>

>>

>>

>>

>>

>> Chairs Decision: No consensus

>>

>>

>>

>>

>>

>>

>>

>>

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

>>

>>

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

>>

>>

>>

>>

>>

>>

>>

>> _______________________________________________

>>

>> RPD mailing list

>>

>> RPD at afrinic.net

>>

>> https://lists.afrinic.net/mailman/listinfo/rpd

>>

>> --

> Lamiaa CHNAYTI




> _______________________________________________

> 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/20201001/fe6b737d/attachment-0001.html>