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

[zouhui <[e-mail]>]

Dear Job,

Thanks for your comments.

Please find my responses in lines.



在 2021年7月9日 18:48，'Job Snijders'<job=[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 :-(
Sorry to not reflect the status quo of AS0 issuance by RIRs. We aimed to show that APNIC、RIPE NCC and AFRINIC already support the AS0 ROA mechanism.


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.


Second, there is a paragraph in B. INR Allocation Conflict of the Section II The INR Conflicts: “Although conflict A is included in the INR conflict model, it is not within the detection scope of the horizontal algorithm. The reason is that this type of conflict can be filtered out by the vertical algorithm, ensuring that RCs and ROAs that dissatisfy the INR encompassing relationship are not taken as inputs of the horizontal algorithm.”
In other words, we consider that the conflict A is also a type of INR allocation conflict, but it is not the detection target of the horizontal algorithm, because it can be filtered by RPs.


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.


Finally, I also very much agree with your view in note 3 that duplication of information can indeed improve robustness. Our work is to provide a method of detecting duplication of information, that is, early warning, and how to deal with it later can be negotiated according to the wishes of the conflicting parties.
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


_______________________________________________
Sidrops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sidrops