What queries to support

[SichangHe]

• [x] Routes for AutNum.
• [x] Reports for AutNum.
• [ ] (Future) Report stats for AutNum.
  • [ ] The number of {OK, Bad, Skipped} rules (@cunha, what does this mean?), fraction of import/exports passing validation, etc.
• [ ] (Future) RPSL stats for AutNum.
• [x] AutNum for report type (meh, etc.).
• [x] AutNum for report item type (a specific special case, etc.).
• [x] RPSL for AutNum.
• [ ] Route RPSL validation status across BGP dumps for a given prefix (@cunha, what does this mean?).

To be changed.

[cunha]

I don't think these are particularly important points for the paper, but they're statistics we might want to have handy (e.g., for the Web interface, and could be nice use cases to cover in the DB assignment):

The number of {OK, Bad, Skipped} rules (@cunha, what does this mean?), fraction of import/exports passing validation, etc.

Here I was thinking we should have info on the RPSL paring results per AS. I think we already have this, but just checking. For example, we want to know which ASes have RPSL errors or use RPSL functionality we didn't implement.

Route RPSL validation status across BGP dumps for a given prefix (@cunha, what does this mean?).

We will see multiple routes for a given prefix (e.g., 150.164.0.0/64). The idea here is to be able to get stats on whether these routes pass or how they fail RPSL validation.

[SichangHe]

Here I was thinking we should have info on the RPSL paring results per AS.

I overlooked this and though you were talking about the reports. If we model the IR to its full semantics in SQL, it would probably be very complicated. So, we would probably store them as JSON, which is harder to query.

[cunha]

I don't remember exactly what I had in mind at the time, but maybe modelling the more important relationships only (AS-to-route, AS-to-organization, AS-to-rules...).

On Thu, Nov 2, 2023, 23:46 Steven Hé (Sīchàng) @.***> wrote:

Here I was thinking we should have info on the RPSL paring results per AS.

I overlooked this and though you were talking about the reports. If we model the IR to its full semantics in SQL, it would probably be very complicated. So, we would probably store them as JSON, which is harder to query.

— Reply to this email directly, view it on GitHub https://github.com/SichangHe/internet_route_verification_server/issues/1#issuecomment-1791831465, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACPO5YZFPUDFPJEHR3ABG3YCRLITAVCNFSM6AAAAAA6O2DXD2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJRHAZTCNBWGU . You are receiving this because you were mentioned.Message ID: @.*** com>

[SichangHe]

From our email exchange:

Hi Steven, I think composing conditions would enable for more "advanced" queries. We should preferably go for queries that have some high-level application. Examples:

• [x] (Future. We don't have Tier-1 in the DB at the moment.) Routes with a Bad import by a provider that traverse a Tier-1 AS --> Potentially harmful route leaks

• [x] Top X ASes with the most Bad imports above --> Who should be looking into their filters

• [x] We could also do the above for Skip::NoImportRules --> Who should be specifying some RPSL rules to improve robustness

• [ ] For each prefix, identify the set of ASes it can reach (as it propagates from right to left in the AS-path) without crossing an Ok report (across all paths for that prefix) --> This would tell us the prefixes that are more problematic

• [ ] Identify the top ASes that originate these prefixes as well as the direct neighbors importing their announcements --> These are somewhat high-risk (in the case of leaks) high-reward (if they were to deploy some filtering) ASes