Re: [Sidrops] The Horizontal INR Conflict-Detection Algorithm: Revealing INR Reallocation and Reauthorization in RPKI

['Job Snijders' <[e-mail]>]

Dear 邵晴,

On Fri, Jul 09, 2021 at 11:54:32AM +0800, 邵晴 wrote:
> I am one of the coauthors of this paper, and this paper is as
> attached，which can be accessed via
> http://dl.ifip.org/db/conf/im/im2021mini/211035.pdf

Thank you, I've read the paper with great interest.

note 1:

On page 3 there is a small error: "Up to now, APNIC [12], RIPE NCC [13]
and AFRINIC [14] have published AS0 ROAs covering the undelegated IPv4
and IPv6 spaces under their management [snip]"
 
At this moment RIPE NCC and AFRINIC do NOT publish AS0 RAOs for
undelegated space. It is my hope it will remain that way, as the
introduction of so-called 'AS0 Trust Anchors' adds considerable
brittleness and fragility to the ecosystem :-(

note 2:

How would it be possible for "INR conflict A" to exist, if the superior
CA has not listed the resource as subordinate. Such objects are
'uncovered' and RPs reject those objects.

note 3:

"INR conflict B" is an interesting case, because one can argue that
different TAs are completely unrelated *different* PKIs, as each TA has
their own Certification Policy (CP). In such an interpretation there is
no conflict.

So rather than considering it a 'conflict', one can argue it is a
duplication of information (a coincidence) and exists to support
redundancy across multiple different PKIs.

I for one would welcome discussion in the RIR community to understand if
the RIRs can set up a service in which they 'mirror' certain delegations
under certain conditions for the resource holder in the other RIR. I
would feel safer if I can publish ROAs via both RIPE NCC and ARIN, while
the INR remains administratively managed by RIPE NCC. These need not be
entirely automated or 'free' (gratis) services. Duplication of
information can be a robustness feature.

conclusion:

Thank you for putting in this work! Whether conflicts should be
considered detrimental 'conflicts', or are productive 'coincidences'
remains an open question, but whatever the name of the thing, monitoring
the global RPKI to spot duplication of information is a worthwhile
activity. I appreciate the hands-on approach in Section E to help
resolve issues.

Kind regards,

Job