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.

Object nameDescription
as-setIt provides a mechanism for publicly documenting the relationship between Autonomous Systems (ASes).
aut-numContains details of the registered holder of an AS number and their routing policy for that AS.
inetnum/inet6numContains 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.
mntnerContains 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.
organizationContains only business information about an organization.
personContains details of technical or administrative contact responsible for the object where it’s referenced.
roleContains 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/route6Represents a single IPv4/IPv6 route injected into the Internet routing mesh.
route-setDefines a set of routes that can be represented by route objects or address prefixes.
Table 1 — Common whois objects (Via APNIC Whois Guide).

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.

as-set <object-name>Mandatory, single-valued, class key 
membersList 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.

A recent name collision has required
Figure 1 — Screenshot of APNIC Whois form showing an error message for non-authenticated as-set creation.

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

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:

no ip prefix-list NN
ip prefix-list NN permit

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:

descr: Aftab Siddiqui Testing AS-SET
tech-c: ISAL1-AP
admin-c: ISAL1-AP
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:

ERROR:Key not found expanding !a4AS-AFTABSIDDIQUI 
no ip prefix-list NN 
! generated prefix-list NN is empty 
ip prefix-list NN deny

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
as-set:     AS-AMAZON
descr:      Amazon ASNs
admin-c:    AC6-ORG-ARIN
tech-c:     AC6-ORG-ARIN
notify:     [email protected]
mnt-by:     MAINT-AS16509
changed:    [email protected] 20151027  #17:32:13Z
source:     RADB
as-set:         AS-AMAZON 
tech-c:         DUMY-RIPE 
admin-c:        DUMY-RIPE 
mnt-by:         KATERINA-MNT 
created:        2022-10-23T19:05:59Z 
last-modified:  2022-10-23T19:05:59Z 
source:         RIPE
Table 2 — The Amazon as-set shown in RADB (left) and RIPE (right) databases.

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.

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.

Dear Colleagues, 

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