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

[Sylvain Baya]

Hi all,

Best wishes for this new year ; added in the Grace era !

Please my comments are below (inline)...

2020-01-03 17:46 UTC+01:00, Owen DeLong <owen at delong.com>:

>

>

>> 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”…

>


Dear Owen,

Thanks for your email.

...yes ! adjusting the subject line helps to focus the discussion,
but i'm not sure that there was a real need in this particular case :-/

...btw, your timing is perfect, with the new year :-D


>

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

>


...not sure !
But if you append ‘intent’ to ‘proposal’ ; then i'll certainly agree ; -)

...please see below.


>

> The proposal creates AS0 ROAs for addresses in the RIR inventory which have

> not been issued or which have been reclaimed or returned.

>


Exact !

...but don't forget that usually, in this PDWG, the title and problem statement
(and even the description of the proposed solution) of a DPP (Draft Policy
Proposal) means nothing.

Yes, that's sad ! but true :'-(


>

> 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 think the following portion of the [1] text explains the concerns
raised by Paschal :

“[...] Any resource holder can create AS0 (zero) ROAs for the
resources they have
under their account/administration.

An RPKI ROA is a positive attestation that a prefix holder has
authorized an Autonomous System to originate a route for this prefix
to the global BGP routing table. An RPKI ROA for the same prefixes
with AS0 (zero) origin shows a negative intent from the resource
holder to have the prefixes advertised in the global BGP routing
table. [...]”
__
[1]: <https://afrinic.net/policy/proposals/2019-gen-006-d1/amp>


>

> I hope that clarifies the situation.

>


...not sure, but you did more for most of the participants, in
promoting RPKI (Resource Public Key Infrastructure), ROA (Route Origin
Autorisation) and ROV (RPKI-based route Origin Validation). So,
validate and drop non-valid routes...

IMHO, what would clarify is to :

•—/
•'drop'/remove that portion of the text :-)
• (eventually) create a sub-section to provide definitions
 for new concepts. The definition sub-section would remove
any ambiguity.
• (even if i think that this proposal is too much operational)
simplify the core policy text like this :
•1| “AFRINIC MUST/will create ROAs with origin AS0 for all
the unallocated and unassigned address space (IPv4 & IPv6)
for which it is the current administrator.”
•2| (i prefer this less operational version) “AFRINIC MUST/will
flag/mark all the unused (unallocated & unassigned) address
space (IPv4 & IPv6) for which it is the current administrator.
In order to render its unused address space unsquattable
in a global secured routing context.”
• ...
•—\

The difference with my version (2|) is that it's more agnostic
(technologcally/operationally speaking) and portable then it
could (probably) more easily pass in all RIRs with the same
text. To be proposed as a global policy : final/first goal of the
authors :-)

...to be clearer, i prefer ‘resource’ rather than ‘address space’ ;-)

Shalom,
--sb.


>

> 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

>

>




--
Best Regards !
baya.sylvain [AT cmNOG DOT cm] | <https://www.cmnog.cm> |
<https://survey.cmnog.cm>
Subscribe to Mailing List : <https://lists.cmnog.cm/mailman/listinfo/cmnog/>
__
#‎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!*» (#Psaumes42:2)