IRR-DB Standards: Adding an attribute to the as-set class

Date created: Thursday, November 2, 2023 5:53:53 PM. Last modified: Monday, December 30, 2024 3:31:15 PM

IRR-DB Standards: Adding an attribute to the as-set class

References:

Intro / Goal

The goal is to add a new attribute to the "as-set" class in IRR DBs which, complements the existing "members" attribute. The "members" attribute states which ASNs a peer should evaluate when generating prefix filters for prefixes received from the local network. Something like an "exclude-members" attribute is needed, to state which members to exclude from evaluation when peers generate these prefix lists. The proposal is that this could be a attribute similar to the members attribute, which can contain one or more ASNs or AS-SETs (comma separated), and one or more instances of the attribute can exist on an object.

What Problems Are Fixed by "exclude-members"?

RFC7682 Section 9 "Security Considerations" highlights that IRR data isn't perfectly authenticated and verified (when entered into the IRR DB), and that IRR operators have the opportunity (not necessarily by intention) to remotely influence the routing of operator networks by manipulating the IRR data retrieved by operators when implanting routing policy retrieved from an IRR. The RFC doesn't point out though, that operators also have the possibility to remotely influence the routing policy of other operators, due to the lack of authentication and validation for IRR data the operators enter into the IRR DBs. Further to this, the WHOIS protocol specifically transfers data in plain text and is unauthenticated. Some DBs have made progress in the area, however others require no authentication and are the authoritative source of data for some networks. If unwanted members are being injected into WHOIS responses (downstream in the AS-tree, a network stores their info in an unauthenticated DB and their management infra has been compromised), or an IRR DB has been compromised, a network operator could update their "exclude-members" attribute to ensure the are not propagating this unauthenticated routing policy information.
RFC7682 also repeatedly points out that the frequency at which IRR data is replicated between IRRs, between IRRs and operators, and implement by operators on their network, is often not at the speed needed by operators in order to deal with daily operational issues as they occur. See section 5 "Operation of the IRR Infrastructure". A customer is usually able to get their upstream to update their prefix list entries within minutes by simply calling or emailing the NOC of the upstream supplier. Updates to the "exclude-members" attribute could be update and applied within minutes. There would be no need to wait for one IRR to update their database, and for that to be mirror by the next IRR, before the upstream provided finally gets the update.

Should This Be Standardised via The IETF?

Lets review the existing literature to try and find out...

What's in the RIPE DB?

RIPE 181

Page 8:
The RIPE database combines both allocation registry and routing registry functions. The RIPE
allocation registry contains data about address space allocated to specific enterprises and/or dele-
gated to local registries as well as data about the domain name space.

From https://apps-test.db.ripe.net/docs/What-is-the-RIPE-Database/Purpose-and-Content-of-the-RIPE-Database/

The RIPE Database holds data for three separate registries:

RIPE Internet Number Registry (RIPE INR) -> Allocation data
RIPE Internet Routing Registry (RIPE IRR) -> routing policy data
Reverse Delegation and ENUM Registry -> DNS data

How Is The Data Formatted?

From: https://apps-test.db.ripe.net/docs/RIPE-Database-Structure/Database-Object/

The records in the RIPE Database are known as ‘objects'. Routing Policy Specification Language (RPSL) defines the basic syntax of database objects. For further information see RFC 2622 (opens new window). But, over the years, practical operations have resulted in a number of deviations from the basic RPSL definition. Many extensions have also been made to the RIPE implementation of RPSL for the RIPE Database. Some features of RPSL were never implemented and others have been removed as requirements changed.

From: https://apps-test.db.ripe.net/docs/RIPE-Database-Structure/The-Attributes-in-Database-Objects/

All objects in the RIPE Database have the same structure. They contain a set of ‘attribute-value' pairs in plain text. These ‘attribute-value' pairs can take different forms. Attributes are sometimes referred to as ‘keys'.

All the database content is currently in Latin-1 encoding. Any characters not in Latin-1 is automatically converted to Latin-1. Any characters without an equivalent in Latin-1 are substituted with a question mark character. One exception is that IDN domain names in email address attributes are automatically converted to Punycode.

Note that RFC2280 Section 2 actually states that ASCII must be used. LATIN-1 is a superset of the 127/128 ASCII chars plus another 128.

Note that RPSL is case insensitive and only the
characters from the ASCII character set can be used.

Where Are AS-SETs Defined?

RIPE-060

This describes the need for a routing registry and how it can be implemented in the RIPE DB using the "route-pr" attribute. "aut-num" is not defined yet.

RIPE-081

This describes the "aut-num" class but, has no definition of the "as-set" class yet.

RIPE-181 (and also RFC1786)

RIPE-181 extends RIPE-81, meaning it also defines the "aut-num" class but, no "as-set" class.

Bottom of page 9:

The autonomous system (aut-num) object provides contact information for the AS and describes
the routing policy of that AS. The routing policy is described by enumerating all neighbouring
ASes with which routing information is exchanged. For each neighbour the routing policy is
described in terms of exactly what is being sent (announced) and allowed in (accepted). It is
important to note that this is exactly the part of the global policy over which an AS has direct con-
trol. Thus each aut-num object describes what can indeed be implemented and enforced locally
by the AS concerned.

Page 30:

9. Representation of Routing Policies
Routing policies of an AS are represented in the autonomous system object.

Page 24:

How to describe the exclusion policy of a certain AS - "as-exclude"

Some ASes have a routing policy based on the exclusion of certain routes if for whatever reason a
certain AS is used as transit. Whilst, this is in general not good practice as it makes implicit
assumptions on topology with asymmetry a possible outcome if not coordinated, this case needs
to be accommodated within the routing policy representation.

The way this is achieved is by making use of the "as-exclude" attribute.

The "as-exclude" class is used to signal to my peers and upstreams that I don't want to receive certain routes from their network. This doesn't solve the issue of telling peers and upstreams to exclude certain routes from my network.

RFC2280 Routing Policy Specification Language (RPSL)

This defines the first version of RPSL which supersedes the NSFNET policy routing database (PRDB) and RIPE routing policy language. The NSFNET was run by the Michigan State University networking division "Merit Network". Merit developed RADB (Routing Assets Database) based off of the original NSFNET policy routing database. RADB is still run by Merit to this day. Merit were also the original developers of IRRd which (at the time of writing) is now on version 4 and fully open source, and has had many contributors over the years since Merit first developed and maintained it.

From Section 1 "Introduction"

RPSL is a replacement for the current Internet policy specification
language known as RIPE-181 [4] or RFC-1786 [5]. RIPE-81 [6] was the
first language deployed in the Internet for specifying routing
policies. It was later replaced by RIPE-181 [4]. Through
operational use of RIPE-181 it has become apparent that certain
policies cannot be specified and a need for an enhanced and more
generalized language is needed. RPSL addresses RIPE-181's
limitations.

The "as-set" class is defined under RFC2280 Section 5.2 "as-set Class".

RFC2280 section 5.2 "as-set Class" also introduces "mbrs-by-ref" attribute to several classes, included the as-set class.

There is also a definition in the RIPE DB docs of an "as-set" which seems to follow the RFC: https://apps-test.db.ripe.net/docs/RPSL-Object-Types/Descriptions-of-Primary-Objects/#description-of-the-as-set-object

What Can/Can't Be Stored in The RIPE DB, and What Is/Isn't Allowed by The RFCs?

There seems to be no clear definition of what can/can't be stored in RIPE (mean, how RFC compliant the data must be):

RFC2280 defines RPSL but, it doesn't define what can/can't be stored in an IRR-DB.
RFC2280 also doesn't say that only the attributes defined in RFC2280 are allowed to be present for each class in an IRR-DB.
Section "2 RPSL Names, Reserved Words, and Representation" even states..
```
Each class has a set of attributes which store a piece of information
about the objects of the class. Attributes can be mandatory or
optional: A mandatory attribute has to be defined for all objects of
the class; optional attributes can be skipped.
```
^ Which means that optional attributes are allowed but, it doesn't defined how to handle unknown attributes though, so it isn't clear if it allows for easy addition of new optional attributes.
On this page, RIPE state that they are not fully RFC compliant because, they have implemented deviations. However, no further clarity is provided as to when and how deviations are implemented.

Examples of New RPSL Additions, Standardised in RFCs, which Affect AS-SETs

The follow is a list of some example updates to RPSL which affects AS-SETs:

RFC2725 Section 9.2 "as-block and aut-num objects" introduces the "as-block" class to track ASN allocations to RIRs.

RFC2725 Section 9.6 "Other Objects" introduces the use of "::" notation to indicate the source of an object:

Many of the RPSL ancillary objects have no natural hierarchy the way
AS numbers, Internet addresses and routes do have a numeric
hierarchy. Some examples are "maintainers", "people" and "role"
objects. For these objects, lack of any hierarchy leads to two
problems.

1. There is no hierarchy that can be exploited to direct queries to
alternate registries. At some point the query strategy of
searching all known registries becomes impractical.

2. There is no hierarchy on which authorizations of additions can be
based.

The first problem can be addressed by considering the name space for
each of the ancillary objects to be unique only within the local
database and to use explicit references to an external repository
where needed. To specify an external repository reference, the
object key is preceded by the name of the repository and the
delimiter "::". For example a NIC handle may take the form
"RIPE::CO19". Currently there is a desire to keep NIC handles unique
so the naming convention of appending a dash and the repository name
is used. Prepending the repository name provides the unique name
space since an object in the RIPE database referencing "CO19" would
be interpreted as "RIPE::CO19" by default, but it would still be
possible to query or reference "IANA::CO19". There is no possibility
of accidentally forgetting to adhere to the conventions when making
an addition and the existing objects are accommodated, including
cases where name conflicts have already occurred.

RFC7909 introduces the "signature" attribute for all existing objects.

The Case for Not Standardising via The IETF

The following is a list of reasons which suggest that the implementation of a new class attribute maybe shouldn't go through the IETF:

A recent RFC has made a change to the RPLS but, it has repurposed an existing optional class attribute, rather the adding a new one, presumably because it would be too painful to get a new attribute added?

RFC9092 Section 3 "inetnum: Class":

The original RPSL specifications starting with [RIPE81], [RIPE181], and a trail of subsequent documents were written by the RIPE community. The IETF standardized RPSL in [RFC2622] and [RFC4012]. Since then, it has been modified and extensively enhanced in the Regional Internet Registry (RIR) community, mostly by RIPE [RIPE-DB]. Currently, change control effectively lies in the operator community

Here, here, and here, in the RIPE documents, the attribute "assignment-size" is referenced but, it isn't defined in any RFC (RFC4012 introduces the inet6num class but, does not introduce the "assignment-size" as an attribute of this class).
RFC7485 Section 4 "RIR Objects Analysis" shows us that the presence of attributes in classes as defined in RFC2262 is not followed and even when the attributes are present, the naming is not as per the RFC.
Only hierarchical AS-SETs can be created in the RIPE DB now, this is not RFC2280 Section 5.4 complaint.

RIPE's own documentation states that they don't strictly conform to the RFCs, from: https://apps-test.db.ripe.net/docs/RIPE-Database-Structure/Database-Object/

The records in the RIPE Database are known as ‘objects'. Routing Policy Specification Language (RPSL) defines the basic syntax of database objects. For further information see RFC 2622 (opens new window). But, over the years, practical operations have resulted in a number of deviations from the basic RPSL definition. Many extensions have also been made to the RIPE implementation of RPSL for the RIPE Database. Some features of RPSL were never implemented and others have been removed as requirements changed.

Handling of Unknown Attributes

If new attributes are added to an IRR-DB (regardless of whether it is handled via a standardisation process or not because, that ship has already sailed!), there needs to be a definition of how tooling should handle new / unknown attributes.

RFC2622 Section 10.2 "Extensions by adding new attributes to existing classes" states the following:

New attributes can be added to any class. To ensure full
compatibility, new attributes should not contradict the semantics of
the objects they are attached to. Any tool that uses the IRR should
be designed so that it ignores attributes that it doesn't understand.
Most existing tools adhere to this design principle.

RFC7909 introduces the "signature" attribute for all existing objects with no indication of whether existing tooling MUST be able to parse this attribute or if ignoring this unknown attribute is acceptable. It is assumed that the RFC Section 10.2 behavior is expected?

Design Details

Reasons for A Dedicated Attribute?

RFC228 Section 7 "dictionary Class" defines the dictionary class. The dictionary class is defined for extensibility but, it is (i) massively over complex for what is required, (ii) seems to be designed for signaling routing protocol configuration, not routing policy, and (iii) the existing attribute "members" has exactly the syntax needed by "exclude-members".

Add a new attribute to a class. RFC2622 Section 10.2 "Extensions by adding new attributes to existing classes" states the following:

New attributes can be added to any class. To ensure full
compatibility, new attributes should not contradict the semantics of
the objects they are attached to. Any tool that uses the IRR should
be designed so that it ignores attributes that it doesn't understand.
Most existing tools adhere to this design principle.

We recommend adding new attributes to existing classes when a new
aspect of a class is discovered. For example, RPSL route class
extends its RIPE-181 predecessor by including several new attributes
that enable aggregate and static route specification.

^ This suggest a new attribute should be added to the as-set class.

RFC9092 places a keyword in the "remarks:" attribute of a route or route6 object. This requires tooling to detect if any "remark" attributes are present, and then parse them all looking for the one which starts with exactly "Geofeed " (case sensitive, and including the trailing space character). This heuristic approach is error prone and thus suboptimal. Now, a free-text field with no official structured format, is expected to follow a specific structured format. We are also now placing operationally important information in a comments field. A more reliable method would be again, a new optional class attribute.
In terms of simplifying understand for users, and implementation for developers, a copy-and-paste of the "members" field would be the path of least resistance (the proposal is for the example same syntax and input validation).

Conflict Resolution

How to handle the case that multiple instance of the "exclude-member" attribute, on the same object (an "aut-num" or "as-set" object), contain the same ASN or AS-SET entry?

In RFC4012 multi-protocol support is added to RPSL however, this introduces the possibility for conflicting data within the IRR:

RFC4012 Section 2.1 "Ambiguity Resolution":

...In these cases,
implementations should follow the specification-order rule as defined
in Section 6.4 of RFC 2622 [1]. To break the ambiguity, the action
corresponding to the first peering specification is used.

RFC2622 Section 6.4 "Ambiguity Resolution":

It is possible that the same peering can be covered by more that one
peering specification in a policy expression. For example:

aut-num: AS1
import: from AS2 7.7.7.2 at 7.7.7.1 action pref = 2;
from AS2 7.7.7.2 at 7.7.7.1 action pref = 1;
accept AS4

This is not an error, though definitely not desirable. To break the
ambiguity, the action corresponding to the first peering
specification is used. That is the routes are accepted with
preference 2. We call this rule as the specification-order rule.

RFC9092 Section 3 "inetnum: Class" suggests a different process, specifically for geofeed data only:

When geofeed references are provided by multiple inetnum: objects that have identical address ranges, then the geofeed reference on the inetnum: with the most recent last-modified: attribute SHOULD be preferred.

^ Top

Previous page: Interop MTUs
Next page: MPLS Label Distribution

Navigation