Koen van Hove writes:
Hello all! I am currently working on a better ASPA UI in Krill. The goal is to provide a bit more confidence when creating an ASPA record that what was entered is correct, and, more importantly, does not accidentally break things once networks start validating and rejecting routes based on ASPA records. The last iteration of that UI can be found here: https://github.com/NLnetLabs/krill-ui/pull/58
I know this topic was also discussed during the last Routing WG in Romania (https://ripe91.ripe.net/programme/meeting-plan/sessions/30/transcript/),
That's a good reference - the discussion around Tim's presentation touched on several important trade-offs. Maybe it's even worth watching the thing[1] rather than (or in additio to) reading the transcript.
and I know the RIPE NCC does not (currently) do this because there are a lot of asterisks. But I wanted to give it a shot anyway :-)
Currently I do two things:
1. Show the likely AS name when you enter an AS number, to prevent simple typos (8283 instead of 8382, etc.);
Very helpful, tools dealing with AS numbers should do so all the time :-)
2. Show which AS numbers appear "to the left" in RIS (without making a claim that they are missing per se, just that they were observed) along with their names.
Yes, see below for a situation in which that could be helpful. (Note that as an ISP I would have to think what "to the left" means in RIS, but hopefully I'd figure it out when I see the whole AS path.)
But as I am not an operator (apart from AS211321, which is a very small network), I wanted your input as well. What is the kind of information you would want (or not want) to see before clicking the "Create ASPA" button?
As an operator, I want to understand the risks. (I'm excluding the case where I don't want to understand, but rather outsource them to someone else; I understand you don't want to be this someone else.) A simple model would be "I need to list all my upstreams as providers in my AS's ASPA - OR ELSE networks beyond those upstreams might drop those routes" (under some conditions that have to do with "valley-free"ness, a concept that ISPs might understand to some degree, but that is not something generally on their minds). If this happens for all transits, the AS will be in big trouble. (Smaller trouble for partial wrongness, left as an exercise...) Hopefully the person preparing the ASPA knows what the AS's upstreams are; otherwise they should go ask someone (or work on the inventory, cf. Ben Cartwright-Cox's remark in the Q&A mentioned above). If a system (such as the Krill UI) makes suggestions, a responsible operator will not blindly accept them, but validate them against their own understanding what the AS'es upstreams are. Possible outcomes: * suggestion = understanding -> "great, that's what I thought!" (but there may be "corner cases" that both are missing, see below) * suggestion ⊃ (is a proper superset of) prior understanding -> Oh, right, I forgot those - thanks! <3, or -> Huh? Why would that one be an upstream?? Maybe subtle difference in opinion on what an "upstream" is or what must be listed as providers in ASPAs. An explanation other than "it was seen in RIS" might be helpful. Helpful data could include: *When* was it seen, where in the path, for which prefixes... * suggestion ⊂ (is a proper subset of) prior understanding -> Ah right, that's not really an upstream (anymore? yet?); Well, let's add them anyway / maybe I shouldn't add it (must trade off risk of valid routes dropped against loss of protection against leaks) -> Huh? Why are those missing Well, let's add them anyway (...) If upstreams are off the recommendation system's radar, it's hard for it to provide useful diagnostics about them. In case of doubt, suggest? * suggestion otherwise not equal to prior understanding -> WTF!? (decompose into two previous cases) Now about the corner cases! An easy (non-corner) case is where I pay other AS for provide me transit to the entire Internet -> they are my AS'es upstream -> I put them in the "providers" field of that ASPA. The other easy cases are: (a) they pay me for transit (they are my customer) and (b) we have a "standard" peering relationship - I announce my customers, they announce theirs -> not my upstream -> don't put them in the ASPA. The "standard peering" case can be recognized relatively reliably by different import: and export: patterns in the aut-num: objects in RIPE DB (or other RPSL routing registries). Of course assuming that those are somewhat well-maintained. Known (to me) exceptions: "Extended peering" (often mutual) / partial transit. You MUST treat the other AS like an upstream for ASPA! If it's mutual, each AS has to include the other in its respective ASPA. This may look weird, but is totally expected and foreseen. You *might* see those in RIS-like systems, but maybe not, depending on whether the limited scope of transit includes vantage points. You might detect such relationships via "unusual" RPSL import/export policies. Informal transit agreements that people tend to forget about (hey, let's all announce this experimental network/IXP service lan/anycast root sever/other special prefix to everyone!) AS8283 in your PR would be an example - maybe they shouldn't bother ever publishing an ASPA at all? Temporary transit: This one's tricky because it may not ever show up in RIS, and I don't think there are well-established conventions how people publish those in the Routing Registry or otherwise. One example are "DDoS protection" providers that announce their customers' prefixes only when an attack is detected (see e.g. "Detecting and Characterizing DDoS Scrubbing from Global BGP Routing: Insights from Five Leading Scrubbers" by Shyam Krishna Khadka, Suzan Bayhan, Ralph Holz, Christian Hesselman, PAM 2026). Another example is "peering with mutual backup transit". One would hope that where ISPs use such arrangements, they test them every once in a while, so they would show up in RIS and could be detected by your system if it looked far enough in the past (or in the future, ahem). But that's maybe too much to ask. Sorry for the long-winded response! Cheers, -- Simon. [1] https://ripe91.ripe.net/programme/meeting-plan/sessions/30/VZNKWV/