algorithm used by (RIPE region) ISPs to generate automatic BGP prefix filters

Mailman List Mirror (Read Only)
1

Hi,

am I correct that ISPs (in RIPE region), who update their BGP prefix
filters automatically, ask their IP transit customer or peering
partner to provide their "route"/"route6" object(s) or "as-set" object
in order to find all the prefixes which they should accept? If the IP
transit customer or peering partner provides an "as-set", then ISP
needs to ensure that this "as-set" belongs to this IP transit customer
or peering partner because there is no automatic authentication for
this, i.e. anybody can create an "as-set" object to database with
random "members" attributes? This is opposite to "route"/"route6"
objects which follow a strict authentication scheme. In addition, in
case of "as-set", an ISP needs to recursively find all the AS numbers
from "members" attributes because "as-set" can include other
"as-sets"? Quite a lot of question, but I would simply like to be sure
that I understand this correctly.

thanks,
Martin

2

Yes you do. Typically, you'll tell the transit provider something like "We are AS23456 announcing AS-STUFF" at order time so they know what to look up.

What then happens is they have something that does the following as either a semi-automatic or fully automatic process:
1) Iterate through AS-STUFF to get a unique list of AS numbers that are involved.
2) Go through this list of ASes, doing an inverse lookup of route or route6 objects with an origin of those ASes.
3) Create filter list from the above list.

The route/route6 objects actually have very weak authentication for out-of-RIPE-region prefixes.

For example, if I want to add a route object for ARIN prefix originating possible. This is currently subject to somewhat of a debate on the mailing lists because of the obvious abuse vector, and there are cases where this has been used to help "legitimise" address space hijacks.

Unfortunately it is hard to simultaneously allow legitimate unauthenticated use without allowing abusive route objects. Which is why there is a lot of head-scratching here; I don't have an answer to that one.

Paul.

3

Hi Martin

am I correct that ISPs (in RIPE region), who update their BGP prefix
filters automatically, ask their IP transit customer or peering
partner to provide their "route"/"route6" object(s) or "as-set" object
in order to find all the prefixes which they should accept?

This is a common practice to do. Both within and outside the RIPE region. For bigger networks, prefix lists become somewhat unwieldy, and one can then use as-path filters instead. Use a prefix limit with this.

Typically you use a tool (bgpq3) to generate the prefix lists.

If the IP transit customer or peering partner provides an "as-set", then ISP needs to ensure that this "as-set" belongs to this IP transit customer or peering partner because there is no automatic authentication for this, i.e. anybody can create an "as-set" object to database with random "members" attributes?

I don't know the procedure for creating as-sets, maybe someone else can chip in.

This is opposite to "route"/"route6" objects which follow a strict authentication scheme.

I believe this differs depending on the irrd software/operator.

In addition, in case of "as-set", an ISP needs to recursively find all the AS numbers from "members" attributes because "as-set" can include other "as-sets"?

Some irrd servers, can expand this automatically (I think). But seriously, use a tool for this.

Quite a lot of question, but I would simply like to be sure that I understand this correctly.

There are basically two abstractions:

1. as-set. Can contain other as-sets or as numbers.
2. prefixes are registered to an as-number.

Remember that there are multiple IRR servers, and they mirror each other.

Use http://irrexplorer.nlnog.net/ to play around a bit :-).

     Best regards, Henrik

  Henrik Thostrup Jensen <htj at nordu.net>
  Software Developer, NORDUnet

4

Hello!

You could check awesome project for this purposes:
http://www.stableit.ru/2015/06/generate-bgp-filters-with-bgpq3.html
It's authored by Russian carrier RETN.net.

5

Yes. We record the customer ASN and the AS-SET for each AFI (v4|v6) and expand these and push updated lists to devices daily or on demand based on customer need.

You should be able to build off any of the mirrored IRRds out there as they all mirror each other, often with minimal lag (5-30 minutes).

The days of fetching via FTP once a day are long gone and a relic of the past.

I recommend using AS-PATH combined with prefix filters to keep your pants on. Rejecting things like networks you may get transit from from customers, and peers helps avoid feeding my route leak system. http://puck.nether.net/bgp/leakinfo.cgi

You should also not be using any IOS devices for BGP as documented in CSCuq14541 where they leak the full table.

- Jared

6

We record the customer ASN and the AS-SET for each AFI (v4|v6) and
expand these and push updated lists to devices daily or on demand
based on customer need.

do you trust the state of the acl on the router and only send a delta,
or do you send the whole acl?

randy

7

We send the whole ACL.

  (infact, we send the full router config each time).

  - Jared

8

We record the customer ASN and the AS-SET for each AFI (v4|v6) and
expand these and push updated lists to devices daily or on demand
based on customer need.

do you trust the state of the acl on the router and only send a delta,
or do you send the whole acl?

We send the whole ACL.

(infact, we send the full router config each time).

i bet that scales well. though i would not trust the router either.

randy

9

it works well enough, software bugs aside. much better than
wondering what state a device is in. our customer migration team
was able to use this toolization to move over 200 discrete interfaces
in one night without error recently.

  having the proper tooling and inventory of customers is
key here. when turning up the first few customers, i get having
a manual process but the ROI on automation is well worth it.

  there's many variations of this graphic out there but
it's important when justifying why you have a network engineer
who can also code and do more than one thing:

http://www.geeksaresexy.net/2012/01/05/geeks-vs-non-geeks-picture/

there's also this related item, you do have to maintain it:

https://xkcd.com/1319/

if you avoid feature creep the tools can be done properly. I've
seen many a project delayed by someone trying to wedge something
in, or alter a schema from one that works to one that is more
technically pure and make it harder to do work.

you must also have the culture that works with the tools, it can't
be the one tool that $powerUser operates, it has to be part
of the busines process.

  - Jared

10

Hi Martin,

well, not only as-set and route.

Assuming only legitimate owner of inetnum and aut-num have passwords for
mntner from that objects can modify their RIPE DB objects and can create
routes.

So to create a route object, you have to have access for inetnum and
aut-num objects (that can be different passwords and owners in general).

Then, you state in your aut-num import and export to some upstream. To
do that, you have to use your password, of course.

Then, your upstream modifying it's aut-num stating import your asn from
you and export your asn to it's upstream... and so on.

So it is possible to provide full chain of trust inside RIPE region that
way.

As-sets is only the way to let manage a lot of downstreams' ASNs more easy.

Many of ISPs using it, there is some software like RETN made, to build
prefix list to your downstreams automatically. And it works.

There is three problems: first, it is only RIPE region specific. You
can't do that with ARIN nets for example. Second, it is RIPE-dependent.
So we depend on RIPE DB when do routing. In some cases it can make some
harm. Third, if someone steal or "recover" RIPE DB password from some
inetnum - he can easy do a hijack through system uses RIPE DB filtering.