algorithm used by (RIPE region) ISPs to generate automatic BGP prefix filters
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
On 04/02/2016 11:14, Martin T wrote:
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.
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 from my RIPE-region AS, there is a dummy maintainer to make this 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.
Hi Martin On Thu, 4 Feb 2016, Martin T wrote:
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
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. On Thu, Feb 4, 2016 at 2:58 PM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
Hi Martin
On Thu, 4 Feb 2016, Martin T wrote:
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
-- Sincerely yours, Pavel Odintsov
On Feb 4, 2016, at 6:58 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
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 :-).
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
On Thu, Feb 04, 2016 at 05:40:36PM +0100, Randy Bush wrote:
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). - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
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
On Thu, Feb 04, 2016 at 05:52:54PM +0100, Randy Bush wrote:
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.
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 -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
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. On 04.02.16 13:14, Martin T wrote:
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
participants (8)
-
Henrik Thostrup Jensen -
Jared Mauch -
Jared Mauch
-
Martin T -
Max Tulyev -
Paul Thornton -
Pavel Odintsov -
Randy Bush