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

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

Owen DeLong owen at delong.com
Fri Jan 3 16:46:03 UTC 2020





> On Dec 30, 2019, at 06:38 , Paschal Ochang <pascosoft at gmail.com> wrote:

>

> Hello Jordi,

> feliz Navidad y un Feliz Año Nuevo.

>

> I have some concerns regarding this proposal and also some clarifications .

>

> I think statistically AFRINIC has a good percentage of IPv4 address space covered by route origin authorization as compared to APNIC. APNIC has a very low percentage statically hence it's hurried acceptance of the proposal.


I corrected the subject line to be descriptive of what is meant by “the proposal/this proposal”…

There’s no relationship between your statement and the proposal.

The proposal creates AS0 ROAs for addresses in the RIR inventory which have not been issued or which have been reclaimed or returned.

It has nothing to do with addresses which have been issued but are not covered by an ROA.

As such, I see no problem with the proposal.


> I think using the approach in this policy is majorly to handle accidental incidents rather than malicious attacks whereby someone might try to manipulate an AS path.


RPKI does nothing at all to help with manipulated AS Paths. It is only effective against prefixes originated from the wrong ASN.

In the case of this policy, it will aid in the prevention/detection of unauthorized use of unallocated number resources.


> It is suggested to always drop invalid announcements, rather than applying a lower preference. This is because sub-prefix hijackings would be still possible if invalids are accepted and this would go against the purpose of RPKI validation. However I think the text should state how invalids should be dropped in order not to trigger loosing connectivity.


I’m not sure how many different ways you think there are to drop a route. At least on the routers I’ve run (Cisco, Juniper, Mikrotik, Vyatta, Ascend, Livingston, Foundry, etc.), you can either drop a prefix or accept it. The decision is binary and there are not multiple “ways” to drop on. In some cases, you can choose additional behaviors such as logging, but I hardly see that as relevant to whether connectivity is preserved or not.

I think what you may be missing in your understanding is that Invalid is not the same as Unknown. RPKI validation provides three possible results:
1. Valid — The route matches a ROA and the ROA matches the Origin ASN. Further, the ROA signature chain is cryptographically valid.
2. Invalid — The route matches a ROA, but either the ROA signature fails validation or the Origin ASN does not match or the prefix length is longer than the specified maximum.
3. Not Found/Unknown — The route does not match a ROA

Note that a prefix which is shorter than an intersecting ROA is considered not to match. See table below for details on how this works out:


ROA Prefix
MAX Length
Origin AS
Received Prefix
Origin AS
Result

192.0.2.0/24
24
65550
192.0.2.0/24
64498
Invalid

192.0.2.0/24
24
65550
192.0.2.0/28
64498
Invalid

192.0.2.0/24
24
65550
192.0.2.0/24
65550
Valid

192.0.2.0/24
24
65550
192.0.2.0/28
65550
Invalid

192.0.2.0/28
28
65550
192.0.2.0/24
64498
Unknown

192.0.2.0/28
28
65550
192.0.2.0/24
65550
Unknown

192.0.2.0/28
28
65550
192.0.2.0/28
64498
Invalid

192.0.2.0/28
28
65550
192.0.2.0/28
65550
Valid

192.0.2.0/24
24
65550
192.0.2.64/26
65550
Invalid

192.0.2.0/24
28
65550
192.0.2.64/26
65550
Valid



> Finally I dont think it will be a nice idea allowing resource holders to create AS0 ROA as I think this scenario might increase the issue of invalid prefixes in the routing tables.


This proposal does not allow resource holders to create AS0 ROAs. It expects AfriNIC to create AS0 ROAs for space which is within AfriNIC administration, but which is not currently issued.

I hope that clarifies the situation.

Owen


>

> On Tuesday, November 5, 2019, JORDI PALET MARTINEZ via RPD <rpd at afrinic.net <mailto:rpd at afrinic.net>> wrote:

> Hi Sylvain,

>

>

>

>

>

>

>

> El 5/11/19 6:11, "Sylvain Baya" <abscoco at gmail.com <mailto:abscoco at gmail.com>> escribió:

>

>

>

> Hi all,

>

>

>

> Hope you are doing well.

>

>

>

> Please comments below (inline)...

>

>

>

> Le mardi 5 novembre 2019, JORDI PALET MARTINEZ via RPD <rpd at afrinic.net <mailto:rpd at afrinic.net>> a écrit :

>

> Hi all,

>

> [...]

> This is the list of new policy proposals (note that the numbering can be modified by the staff when published).

>

> 1) AFPUB-2019-IPv6-002-DRAFT01: "Adjusting IPv6 PA Policy"

> Solves a discrepancy between IPv6 PI and IPv6 PA regarding the announcement of aggregated addressing space.

>

> 2) AFPUB-2019-GEN-003-DRAFT01: "Chairs Elections Process"

> Including in the CPM a detailed procedure for the chair's elections.

>

> 3) AFPUB-2019-GEN-004-DRAFT01: "M&A Resource Transfers"

> Including in the CPM intra-RIR M&A for ASN, IPv4 and IPv6.

>

> 4) AFPUB-2019-GEN-005-DRAFT01: "Impact Analysis is Mandatory"

>

> 5) AFPUB-2019-GEN-006-DRAFT01: "RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space"

>

>

>

> ...i like this one. I recall that i was thinking ok how to solve the problem of 'Internet resources

>

> squatting'. I was naively imagining a solution where a RIR will have to flag all their

>

> unallocated|unassigned Address Space ; via a particular attribute of the IRR (Internet Routing

>

> Registry). Now i understand that i was not too dummy or even crazy :-)

>

>

>

> Oh no! In that case the crazy one is me :-) !

>

>

>

> Please send me your DPP (Draft Policy Proposal), i can not wait more to review it ;-)

>

> Thanks.

>

>

>

> I was thinking in sending them in order (2 more today, 2 more tomorrow), but as you have interest in this one. My next one will be this one, I promise! Give me first a few minutes to respond to all the emails I got till now …

>

>

>

> Shalom,

>

> --sb.

>

>

>

> Updated policy proposals:

>

> a) AFPUB-2019-ASN-001-DRAFT03: "Multihoming not required for ASN"

>

> b) AFPUB-2019-IPv4-002-DRAFT02: "IPv4 Inter-RIR Resource Transfers (Comprehensive Scope)"

>

> c) AFPUB-2018-GEN-001-DRAFT04: "Abuse Contact Policy Update"

>

> Regards,

> Jordi

> @jordipalet

>

> [...]

>

>

>

> --

>

>

>

>

>

> --

>

>

>

> Best Regards !

>

>

>

> Sylvain BAYA

>

> cmNOG's Co-Founder & Coordinator

>

> (+237) 677005341

>

> PO Box 13107 YAOUNDE / CAMEROON

>

> baya.sylvain [AT cmNOG DOT cm]

>

> abscoco2001 [AT yahoo DOT fr]

>

> http://www.cmnog.cm <http://www.cmnog.cm/>

> https://cmnog.wordpress.com <https://cmnog.wordpress.com/>

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

>

> ‪#‎LASAINTEBIBLE(‪#‎Romains15:33):"Que LE ‪#‎DIEU de ‪#‎Paix soit avec vous tous!‪#‎Amen!"

>

> ‪#‎MaPrière est que tu naisses de nouveau.

>

> ‪#‎Chrétiennement

>

> « Comme une biche soupire après des courants d’eau, Ainsi mon âme soupire après toi, ô DIEU! » (Psaumes 42 :2)

>

>

>

>

> _______________________________________________ RPD mailing list RPD at afrinic.net <mailto:RPD at afrinic.net> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>

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

> IPv4 is over

> Are you ready for the new Internet ?

> http://www.theipv6company.com <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


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


More information about the RPD mailing list