per prefix as-path validation

[lukastribus]

I would like to bring @m0yellow 's request over from snar/bgpq3#59 :

Hello,
I'm searching for a solution to filter the routes an AS sends me, and if they are originate from the right AS.

Principle:
when peering with 64500, it sends me its own routes, plus the routes of their customers.
Due to frequent configuration error, 64500 sends me route of Customer 64510 as their own.

This leads to potential routing problems, but also extended troubleshooting on my side, as this route is obviously filtered in some places.

Is there a possibility to output further filters, when querying for an as-set, to have the routes group by orgin AS?
This would immediately filter those wrong announcements.

From my current point of view (as I'm using JunOS), this could be easily accomplished with a configuration block a this:

# show | compare 
[edit policy-options]
+   policy-statement PERMIT-AS64500-IN {
+       term AS64500-ROUTES {
+           from {
+               as-path AS64500;
+               route-filter 192.0.2.0/24 exact;
+           }
+       }
+       term AS64500_AS64510-ROUTES {
+           from {
+               as-path AS64500_AS64510;
+               route-filter 10.0.0.0/23 upto /24;
+           }
+       }
+   }
[edit policy-options]
+   as-path AS64500 64500+;
+   as-path AS64500_64510 "64500+ 64510+";

When included as import filter, this allows both networks to prepend their path as needed, but disallows an origin not documented in the RADB.

I have multiple use cases for this filters, and I hope I'm not alone with this, as I would have to script it externally (due to lack of skills in C).

Per prefix as-path validation may be out of scope ... or not. Let's discuss. It would be nice to have, but it may not be worth the effort, especially for multiple platforms.

[job]

can you write C? Lets build it!

[lukastribus]

I'm not sure I'm up for the job, I have only very basic C skills. My intention was merely to bring the idea up here for discussions.

However, I believe I may have already found a showstopper: how can we construct the specific as-path from IRR data in the first place?

Suppose AS20/Bob is a small Tier2 providing transit for AS300 and AS301. So the as-set looks like:

as-set:          AS-BOBAS
descr:           Bob's AS and it's customers
members:         AS20 # Bob's AS
members:         AS300 # Francis
members:         AS301 # Pete

Of course the as-paths are the following:

20
20 300
20 301

But really we know that by reading the description and applying good old human logic. I'm not sure how we would be able to determine those as-paths from actual code.

I don't think we should invent our own heuristics ... like the transit as is always the first as in the as-set, that's just an assumption.

So I'm not sure how we would be able to do this with IRR/RPSL data?

[lukastribus]

Validating the origin-as at the other hand should of course be possible.

[m0yellow]

As the original requestor, I had my eye on nested AS-Sets.
in your Example AS20 includes AS-CHARLIE, which is AS400, and includes AS401 and AS402.
We have one customer which AS-Set is at least four levels deep (I didn't check further).

[hadeshimself]

I was trying to achieve the same and found this thread. That's right, there's no implicit hierarchy in the AS-SETs. You can't even properly track the AS-SETs to an ASN.

[m0yellow]

I work in RIPE Land, and in my use-case we can track from the ASN what they announce. I work for a Tier2/Tier3 ISP, and we usually start by the customer ASN, and resolve it mostly manually. So it might not be obvious, but with a good run away protection in the algorithm you can determine the AS-SET used by any AS, which is the way I need it. There are some edge-cases like circular AS-SET inclusions, but I've never found them hard to solve.