A self-hosted approach to increase AS transparency and to support future internet applications

Autonomous systems and their metadata

The internet transports data across a network of independently operated autonomous systems (ASes), each of which consists of the networks, routers, switches and other infrastructure owned and managed by a given administrative entity (“a manifestation of infrastructure ownership and the need for autonomous administrative control”, as this SIGCOMM paper calls it).

An AS announces reachability for one or more IP address blocks that it is authoritative for using the Border Gateway Protocol (BGP). BGP “gossips” this information across the internet so that ASes can dynamically establish paths from any source AS to any destination AS via intermediate ASes. These AS paths ultimately carry traffic from the hosts connected to the source AS to hosts in the destination AS.

In addition to sharing reachability information using BGP, AS operators also publish connectivity attributes through Internet Routing Registries (IRRs) and using PeeringDB. The records in those databases enable ASes and other entities to check which internet routes an AS is authoritative for, to contact an AS’s administrators, and to find out where to peer with the AS, for example. Both are logically centralised systems, with IRRs being operated by Regional Internet Registries, such as RIPE NCC. However, the frequent presence of outdated data in IRRs is a known problem.

Critical infrastructure use cases and internet routing

We envisage that the internet of the future will not only serve today’s applications, such as email, content distribution and video conferencing, but will also become the communications substrate for the control of distributed critical infrastructures such as power grids, tele-robots and the remote control of trucks. We hypothesise that this will impose new security requirements on the internet’s core components, such as the routing system and IRRs.

One particular new use case that we envisage is that operators of critical infrastructures will want to have more control over their AS paths, so that they can route traffic via ASes that they consider trustworthy. For example, we imagine the operator of a future smart energy grid will want to route powerline switching instructions from the control room to a faraway field station via one or more chains of ASes that have been successfully security-audited, are owned by organisations registered with local or regional Chambers of Commerce, and can attest that their routers are in a secure state. Managing AS paths in that way would be similar to the way that organisations such as Boeing manage their multi-tier supply chains, with in our case each AS being similar to a tier in a service provider's “communications supply chain”.

We imagine that the deployment of these path security functions and policies will take place through so-called “trust zones”. Trust zones are MANRS-like coalitions of ASes that collaboratively implement security policies on a regional scale rather than globally. A trust zone may for instance ask its ASes to set up their routing policies so that traffic is safely routed between the members of the trust zone, and to provide the necessary audit trails to attest that that is the case. It will, however, take a substantial amount of research and implementation work to determine whether it is feasible for ASes to collaborate in that way. Some of those challenges are being researched in the CATRIN project.

Requirements for an extended AS information service

In the future, to enable trust-sensitive parties such as power grid operators to assess the trustworthiness of the ASes along an AS path, we will need an “AS Information Service” (ASIS) that provides detailed security and administrative attributes about ASes, going beyond the connectivity attributes in IRRs and PeeringDB. Examples of such attributes include the security certification level of an AS, cryptographically verifiable data about the owner of the AS, security contact information (“AS-wide security.txt”), what data laws apply, and operational information (equipment types, software versions, network topology).

We have identified four requirements (R1 to R4) for such an ASIS:

R1. Self-hosted

An ASIS should be self-hosted, which means that every AS operator should run its own ASIS instance. This is important so the AS operator owns its ASIS and is accountable for the data in it. Also, a previous proposal to add attributes for GDPR and human rights compliance to IRRs led to the conclusion that such information should be kept separate from connectivity databases. As a result of the ASIS’s decentralised nature, clients will need a discovery mechanism to locate the ASIS of a particular AS.

R2. Granular access control

To balance security, end-user privacy and transparency, an ASIS should enable an AS operator to control which AS attributes it wishes to disclose to whom and at what level of granularity. For example, an AS may be willing to share data about the router vendors it uses with other AS operators that are members of the same trust zone (see above) and have signed legal agreements on the receipt of such information. At a minimum, an ASIS should disclose connectivity attributes, either locally or through a pointer to an IRR or to PeeringDB.

R3. Interfaces with network management systems.

An ASIS should interface with the network management systems of an AS, so the AS operator can update it (semi-)automictically. The ASIS data can then easily be kept up to date, increasing its practical value. Outdated data about ASes is known to be a problem in central databases such as IRRs, perhaps because they do not have such interfaces. An AS operator might also publish third-party data through their ASIS, such as performance measurements and reachability information collected from networks around the world using RIPE ATLAS.

R4. Uses common data formats

For interoperability and machine readability, an ASIS should provide security and administrative attributes in a well-defined and preferably IETF-standardised format, such as the Routing Policy Specification Language for connectivity attributes in IRRs.

Existing systems for AS metadata

Existing systems, such as IRRs and PeeringDB, do not meet the requirements for an ASIS, for instance in terms of granular access control and because they are logically centralised. The same goes for third-party measurement systems that form alternative sources of AS metadata, such as RIPE ATLAS, OpenINTEL and ALTO servers. Other sources are weblogs (e.g. Cloudflare’s) and mailing lists (e.g. NANOG and NLNOG), but they provide unstructured AS data, which is more difficult to interpret.

A previous ethnographic study proposed adding attributes for GDPR and human rights compliance to IRRs. The proposal met with resistance from the routing community, and the author has provided some interesting insight into why the community rejected it. We expect that a grassroots approach with small communities of ASes (trust zones) sharing extra AS information with one another on a regional scale may be a more viable solution than seeking consensus within the global routing community.

High-level design of the AS information service

Figure 1 shows our high-level design of the ASIS. Each AS is responsible for running its own ASIS instance (requirement R1). Information in the ASIS can be entered manually by an administrator or automatically by means of an automated interface with a network management system (NMS) or configuration management database (CMDB), as represented by step 1 in Figure 1 (requirement R3). The ASIS can also be used as a tool to automatically update logically centralised databases, such as RIRs (step 2).

Figure 1. High-level ASIS design.

To get data about an AS, a client first needs to look up that AS’s ASIS, for instance using an IP address from the ranges that the AS is authoritative for (step 3). Next, it can send a request to get the AS metadata (4). If the user or service is authorised to access the data (requirement R2), the ASIS sends the data back, formatted according to a suitable open standard (requirement R4).

A first ASIS prototype

To get a feel for the feasibility and added value of an ASIS for ASes and network operators, we built a simple prototype implementation.

We focused on requirement R1 (self-hosting). This allowed us to discuss with stakeholders what kinds of data they would like to share through their ASISes and get from other ASes, and to determine the granularity of access control they would require. Our prototype can also be used to demonstrate multi-domain information retrieval for a given AS path by integrating it with our visualiser, PathVis.

To keep things simple, we decided on an HTTPS-based implementation for the ASIS, and on the use of static JSON files for sharing data. In due course, support for other document formats and for dynamic data input from other systems can be added. HTTP also supports basic authentication, which gives us options for meeting requirement R2 (granular access control) in the future.

Since each domain runs its own ASIS instance, we need a lookup service to find the ASIS that is associated with an AS.

DNS-based ASIS lookup service

We use the Domain Name System (DNS) as a lookup service for the ASIS. In particular, we use reverse zones, which map an IP address back to a host name. We use this mechanism so that clients can locate the ASIS of an AS by querying the DNS for any of the IP addresses that the AS is authoritative for. In return, the client gets an ASIS TXT record that we defined (formatted according to RFC 6763, Section 6) and that points to the ASIS.

Let’s look at an example (Figure 2). A client does a lookup on the reverse zone of IP address 203.0.113.0 (interaction A) and then obtains the ASIS DNS TXT record (B), which is:

TXT IN v=ASISv1 ep=https://asis.example.nl/asis/v1

The “ep=” field (for “ASIS end point”) points to the ASIS and the “v=” field is the version of the ASIS protocol, which we set to v1 for this example.

Finally, the client can contact the ASIS using the URL in the “ep” field (C), which will then respond with the security and administrative attributes (D). Interaction (D) maybe subject to access control, depending on the AS operator’s policies.

Figure 2. Example of ASIS discovery.

Using the DNS to resolve ASIS instances places an administrative responsibility on the administrators of reverse zones. Adding ASIS TXT records for every IP address by hand would be error-prone and not readily scalable. Those problems could be resolved by automation and the addition of support to authoritative DNS server software.

Summary and future work

We believe that a more transparent internet will be important for the critical applications of the future, because it will enable them to get more insight into and control over the security and administrative properties of AS paths and thus over their “communications supply chain”. The concept of an ASIS is one way to make this kind of AS path transparency a reality. Large-scale deployment will be a major challenge, but might work if groups of ASes (trust zones) collaboratively adopt the ASIS, which would create initial “pockets” of AS path transparency.

We have proposed a set of initial requirements for the ASIS, and we have designed and implemented a simple prototype of the system based on an HTTP server. A great deal more work remains to be done, however. For example, to fulfil requirements R2 to R4, we first need input from the community regarding the information that network operators might want to share and with whom (requirement R2). From there we can determine what network management systems an ASIS needs to interface with (R3), and what standards can be used to describe the metadata in an ASIS (R4).

What kind of AS data would you want to share using the ASIS, and under what conditions? Let us know at sidnlabs@sidn.nl.

Acknowledgements

This work was conducted as part of the CATRIN project (www.catrin.nl), which received funding from the Dutch Research Council (NWO).