Why Network Operators Should use Hierarchical as-sets
There has been a lot of discussion on network operator lists recently about changes to ‘as-set’ objects because of security concerns. I thought it may help to provide some context to this discussion to clarify the significance of these changes to MANRS participants and others interested in securing the routing system and why from the MANRS perspective, we encourage all network operators to use hierarchical as-set even if you’re a stub network.
The Underlying Problem
If you’re a network operator of any size and have received number resources (IPv4, IPv6, or an Autonomous System Number (ASN)) then part of running your network requires setting up Border Gateway Protocol (BGP) peering sessions with other networks to exchange routing information.
BGP provides flexibility and scalability to accommodate Internet growth. But, because it’s based on trust, without any built-in security mechanisms, problems do occur. For example, it’s not unusual for BGP users to accidentally send routes to peers they’re not supposed to because they typed in the wrong routes.
Unfortunately, these mistakes can cause outages and with it financial and reputational damages for your network and others, and they can impact the whole Internet.
Filtering is the recommended way to fix this problem and is the most important and mandatory action (Action 1) of the MANRS initiative. Network operators are encouraged to implement filters based on the Internet Routing Register (IRR) and Resource Public Key Infrastructure (RPKI).
When setting up a BGP session, it’s important to decide on:
- The prefixes you’re willing to accept from your peer —whether it’s the full global routing table or a sub-set of it based on certain internal policies.
- Which prefixes are you authorized to advertise to them.
Because you can’t trust whether everyone is advertising their prefixes correctly, the IRR developed Routing Policy Specification Language (RPSL), which automatically verifies routing policies and announcements that are uploaded to the IRR. The IRR consists of several globally distributed routing information databases. Some notable IRR instances include RADb, ALTDB, and most importantly those run by the Regional Internet Registries (RIRs). RIRs allow you to create objects defined by RPSL in their databases, which can be used to verify the information and can generate BGP filters and prefix lists using whois queries.
Each record in an IRR database contains — a set of attributes with corresponding values, which describe things such as people, organization, IP addresses, AS numbers, routing policy, and network/abuse contact information. Table 1 describes some of the most commonly used objects.
|as-set||It provides a mechanism for publicly documenting the relationship between Autonomous Systems (ASes).|
|aut-num||Contains details of the registered holder of an AS number and their routing policy for that AS.|
|inetnum/inet6num||Contains details of an allocation or assignment of IPv4/IPv6 address space.|
|irt (APNIC) abuse-c (other RIRs)||Incident Response Team. It’s used to provide information about the contact details of the abuse handling team.|
|mntner||Contains details of the authorized agent able to make changes to Whois Database objects. Also includes details of a process that verifies that the person making the changes is authorized to do so.|
|organization||Contains only business information about an organization.|
|person||Contains details of technical or administrative contact responsible for the object where it’s referenced.|
|role||Contains details of technical or administrative contacts as represented by a role, performed by one or more people within an organization, such as a Helpdesk or Network Operations Centre.|
|route/route6||Represents a single IPv4/IPv6 route injected into the Internet routing mesh.|
|route-set||Defines a set of routes that can be represented by route objects or address prefixes.|
So, What is an as-set and why do They Need Changing?
An as-set provides a way to document the relationship between ASes which can then be publicly verified.
The as-set attribute defines the name of the set. It is an RPSL name that starts with “as-“. The member’s attribute lists the members of the set. The members attribute is a list of AS numbers, or other as-set names.
Attribute Value Type as-set <object-name> Mandatory, single-valued, class key members List of <as-numbers> or <as-set-names> Optional, multi-valued mbrs-by-ref List of <mntner-names> Optional, multi-valued RFC 2622 Section 5.1
An as-set serves the purpose of describing which networks compose the so-called ‘customer cone’ of an AS you peer with. By adding a ‘member’ attribute pointing to either an ASN or to another as-set, an entity is indicating which prefixes should be accepted by their BGP Neighbors. Here are two examples from Australian networks:
as-set: AS-IPTRANSIT descr: IP Transit tech-c: ITPL4-AP admin-c: ITPL4-AP mnt-by: MAINT-IPTRANSIT-AU members: AS64098 members: AS134720 last-modified: 2017-05-10T17:50:45Z source: APNIC as-set: AS4826:AS-VOCUS descr: Vocus Communications AS4826 AS-SET members: AS4826, AS4826:AS-CUSTOMERS admin-c: VPL1-AP tech-c: VPL1-AP remarks: For queries please email the below contacts remarks: NOC - [email protected] remarks: IRR Data - [email protected] remarks: Peering enquiries - [email protected] notify: [email protected] mnt-by: MAINT-AU-VOCUS last-modified: 2022-05-29T00:28:23Z source: APNIC
Note, AS4826:AS-VOCUS (hierarchical) has a different as-set structure to AS-IPTRANSIT (non-hierarchical). Both are correct, as RFC 2622 explains, which applies to all ‘set’ objects such as as-set, filter-set, and route-set:
Set names can also be hierarchical. A hierarchical set name is a sequence of set names and AS numbers separated by colons ‘:’. At least one component of such a name must be an actual set name (that is, start with one of the prefixes above). All the set name components of a hierarchical name have to be of the same type. For example, the following names are valid: AS1:AS-CUSTOMERS and AS1:RS-EXPORT:AS2.RFC 2622
Now, to understand the problem and why the hierarchical as-set is important, take a look at the following example:
as-set: AS-AFTABSIDDIQUI descr: Aftab Siddiqui Testing AS-SET tech-c: ISAL1-AP admin-c: ISAL1-AP mnt-by: MAINT-ISAL-SG members: AS139038 last-modified: 2022-12-16T03:10:12Z source: APNIC role: Internet Society Asia Limited administrator address: 3 Temasek Avenue Level 21 Centennial Tower, Singapore country: SG phone: +65-6549-7138 e-mail: [email protected] admin-c: ISAL1-AP tech-c: ISAL1-AP nic-hdl: ISAL1-AP mnt-by: MAINT-ISAL-SG last-modified: 2020-06-12T07:37:44Z source: APNIC
It looks like a normal non-hierarchical as-set object with my name on it. The only problem is it was created by MAINT-ISAL-SG and the Internet Society which has neither any relation with AS139038 nor is authorized (ethically) to create such objects. However, they technically can create this object because it’s permissible as per the RIR policy: it doesn’t contradict the standard outlined in the RFC for non-hierarchical objects.
However, if they try to create an as-set in a hierarchical format this is what they get.
This is perfect! It shows that MAINT-ISAL-SG is not authorized to create an as-set for my ASN.
What is the Significance of Creating an as-set With a Bogus Name?
I mentioned earlier, network operators are encouraged to implement filters based on the IRR and RPKI. While the valid RPKI ROA status of routes in the global routing table is growing (as of December 2022, it is just above 40%), implementing IRR-based filtering is a great starting point.
If I’m a network operator who wants to build a prefix filter for AS58280 then I can simply use bgpq4 (A BGP Filter Generator). For example:
$ bgpq4 as58280 no ip prefix-list NN ip prefix-list NN permit 22.214.171.124/22
This is easy for AS58280 because it’s a stub network and doesn’t have downstream customers. But if I need to generate similar data for an operator with hundreds of downstream customers, then this method doesn’t scale and that’s why we use an as-set.
Instead of passing an ASN as the argument to bgpq4, I can pass as-set as an argument, like so:
$ bgpq4 -S APNIC AS-AFTABSIDDIQUI no ip prefix-list NN ip prefix-list NN permit 126.96.36.199/24
In the example above, I used AS-AFTABSIDDIQUI. The as-set was not created or managed by me. It worked because the as-set has the right member, AS139038, which is my ASN. But if MAINT-ISAL-SG decides to delete the member attribute from the as-set then there would be a problem. To overcome this, first, update the as-set:
as-set: AS-AFTABSIDDIQUI descr: Aftab Siddiqui Testing AS-SET tech-c: ISAL1-AP admin-c: ISAL1-AP mnt-by: MAINT-ISAL-SG last-modified: 2022-12-16T04:40:25Z source: APNIC
Once the as-set has been updated and the ‘member’ attribute has been deleted from the object, re-run the bgpq4 for the same as-set:
$ bgpq4 -S APNIC AS-AFTABSIDDIQUI ERROR:Key not found expanding !a4AS-AFTABSIDDIQUI no ip prefix-list NN ! generated prefix-list NN is empty ip prefix-list NN deny 0.0.0.0/0
Without the member attribute, it will simply generate a blank prefix list causing traffic from AS139038 to be dropped by those operators using AS-AFTABSIDDIQUI for filtering purposes.
You may ask why would I give AS-AFTABSIDDIQUI to anyone knowing that I didn’t create that as-set?
This brings us to the problem that has set off this discussion about needing to create hierarchical as-sets and has to do with a thing called ‘name collision’, which is a situation where two items/variables/objects have the same name within different databases but are connected.
In the above scenario, I used the APNIC Whois database. However, there are five RIRs and many other non-authenticated IRRs such as RADb and ALTDB.
A recent high-profile name collision happened when a Local Internet Registry created an as-set in the RIPE database for Amazon. At the same time, the original as-set was created elsewhere (in RADb) (Table 2).
|By Maintainer (Amazon)||NOT by Maintainer|
descr: Amazon ASNs
members: AS-AMAZON-NA, AS-AMAZON-AP, AS-AMAZON-EU
notify: [email protected]
changed: [email protected] 20151027 #17:32:13Z
|as-set: AS-AMAZON |
Without going into the details of whether it was/is a malicious attempt to create routing problems for Amazon, this is something that must not be allowed.
Thanks to the efforts of Job Snijders, Ben Cox, Nick Hilliard (MANRS Steering Committee Member), and many others, the community has moved quickly and proposed a change to its Whois policy.
How to plug one of many holes in the IRR: from community proposal https://t.co/8UiY61CnHL to testing https://t.co/OASXXIra36 to deployment https://t.co/3792nizQZl in 29 days. Kudos to the @ripencc database team!— Job Snijders (@JobSnijders) December 13, 2022
And on 13 December 2022, RIPE implemented the change in its production database. Now, non-hierarchical as-set creation is not possible in the RIPE Whois.
We have now deployed Whois 1.105 to production. This completes NWI-19, creating short format AS-SET objects is no longer possible.Email from Ed Shryane, RIPE NCC, notifying members of Whois changes.
From the MANRS perspective, we encourage all network operators to use a hierarchical as-set even if you’re a stub network — see the MANRS implementation guide.
If you are a network operator, implement MANRS Actions and join the MANRS community.
Leave a Comment