NRO-Stats as a Complementary DataSource - Tagging and validating Objects based on that #415
Replies: 4 comments
-
How this validation against NRO Data Source could be used to separate the wheat from the chaff? Considering Origin Validation, Let's classify the Routes in DFZ, Route/Route6 Object in IRR, in 3 cases: 1 - Most of the authentic Routes in DFZ are originated by an ASN Owned by the same organization(opaque-id) that Owns the IP Block containing that prefix of the route. 2 - And most of the spurious Routes that appear in DFZ time-to-time are originated by some ASN Owned by organizations different than that one that owns the IP Block containing that prefix of the route. 3 - There is a gray area between those two cases. And only a small set of it can be considered authentic. If we could classify cases 1 and 2, it would be easy to reinforce the public demand for the publication of ROAs RPKI to those in case 3 so that they are not confused with those in case 2. This does not mean dispensing RPKI ROAs in case 1. |
Beta Was this translation helpful? Give feedback.
-
So, if I'm understanding this correctly, the NRO-stats data would not give a definitive "this is invalid" answer, but a "this is potentially suspicious"? My concern in that case is that we can present this in an attribute, but that I'm not sure anyone would look at it. Automated tools like bgpq4 certainly won't. With RPKI, we get a clear "this is invalid" answer, as there are no cases where valid route objects are somehow RPKI-invalid: RPKI is considered the absolute source of truth. But it doesn't sound like the NRO-stats data would be definitive enough to actually delete/hide objects? |
Beta Was this translation helpful? Give feedback.
-
Give the possibility do IRR information consumers the possibility to do a query based on that attributes could be considered an "extra" feature. Something that maybe could be "easy" to deliver after all the skeleton of NRO-stats validation being ready... The major goal is to deliver to IRRD administrators the possibility of choosing behaviors based on those attributes. Some practical examples:
That the idea! [1] When I say "we", it actually means you all involved until now! |
Beta Was this translation helpful? Give feedback.
-
AntartidaNICIRR would use 'scope filtering' https://irrd.readthedocs.io/en/stable/admins/scopefilter.html The DougInetReg situation is harder, but is partially solved by RIPE-731 style RPKI based IRR filtering |
Beta Was this translation helpful? Give feedback.
-
Incorrect/Invalid Objects in IRR are a headache!
They exist because of the lack of appropriate validation in the past.
But today in before is possible to Identify, Classify, and based on that decide to block (or not) the Invalid Incorrect/Invalid objects creation, or even decide to remove/hide already existent Incorrect/Invalid objects.
If NRO Delegated-Extended file [1] could be used as a Data Source(similar to what is done with RPKI ROAs), would be possible to create some additional attributes and validations to each object on its Creation/Importing.
To avoid difficulties in how these tags would fit the current list of permitted attributes, it could be done with some internal standardized remarks.
P.S.1: I Believe this proposal overlaps with issue #7
P.S.2: I know this proposal overlaps RPKI concepts. But I tend to believe that the effort required will be overcome by the positive results.
Obs.: "Opaque-ID" is a unique identifier of each Organization on NRO and RIRs, and is explained on NRO-Stats Readme [2].
A single Organization can own several ASNs with a single "Opaque-ID"
Examples:
Additional Attributes:
a) On Maintainer, Aut-Num objects creation/importing, tag each one with the equivalent "Opaque-ID" referent to its organization.
b) On Aut-Num, Route, Route6, objects creation/importing, tag each one with the respective RIR/LIR/NIR name.
Additional Validation:
c) On Aut-Num, Route, Route6 objects creation/importing, compare the "Opaque-ID" of the maintainer from that object with the "Opaque-ID" of respective Object that is being processed:
d) On Route, Route6 objects creation/importing, compare the "Opaque-ID" of Origin ASN Informed at the object with the "Opaque-ID" of the respective prefix of the Object that is being processed:
Some extra logical analysis could be done on strict validation mode:
e) Some IRRs have the policy of no accepting objects not from specific RIR/LIR/NIR.
Ex.: RIPE
f) Some IRRs have the policy of no accepting proxy objects.
Ex.: TC
P.S.: If all IRRs adopt this policy, I would love it.
g) If Route(6) has "is-proxy yes" and "is-subdelegated yes" it's almost a certainty that it is an incorrect/invalid object.
(Better explained below)
h) Some combination with rpki-ov-state could be done.
[1] https://nro.net/wp-content/uploads/apnic-uploads/delegated-extended
[2] https://www.nro.net/wp-content/uploads/nro-extended-stats-readme5.txt
Beta Was this translation helpful? Give feedback.
All reactions