Explicitly excluding objects from RPSL sets

Introduction The Routing Policy Specification Language (RPSL) defines the as-set and route-set classes, whose objects are held in the Internet Routing Registry (IRR). A set can reference direct members, such as an AS number or address prefix, and it can reference other sets. Those sets can reference further sets, recursively. Server and client software resolve a set by following these references until it is reduced to a set of prefixes or AS numbers. The result is used mainly to build filters on routers.

Existing Methods of Inclusion Existing RPSL syntax offers several ways to include members in an as-set or route-set: The members attribute. On an as-set it holds AS numbers and as-set primary keys (). A route-set's members are address prefixes. Its members attribute contains an IPv4 address prefix or a route-set primary key, each optionally followed by a range operator (). It may also contain an AS number or an as-set primary key, which per stand for the routes originated by that AS, or by the ASes in that as-set. The mp-members attribute for route-sets (), which takes the same values as members and adds IPv6 address prefixes. Like members, this may contain an AS number or an as-set primary key. The mbrs-by-ref and member-of attributes. These add an AS to an as-set through its aut-num object, or a route object's prefix to a route-set, when that object's member-of names the set and the set's mbrs-by-ref lists one of the object's maintainers or ANY, per Sections and of . extends this to route6 objects.

Resolving Members of a Set Resolving a set means working out which AS numbers or prefixes it includes. A resolver reads the set object and, wherever a member names another set, reads that set as well, continuing until it reaches members that are AS numbers or address prefixes. Those members are the result. In practice, implementations place limits on the depth and detect loops. A set that names another as-set or route-set in (src/mp-)members is called the including set, and the set it names the included set. Everything an included set resolves to becomes part of what the including set resolves to. In , AS-EXAMPLE-A1 lists a single member. It resolves to AS64500, AS64501 and AS64502:

This also applies when a route-set references another route-set or as-set.

Existing Methods of Exclusion The filter-set class () defines a set of routes by describing what its filter attribute matches. adds mp-filter, which covers both address families. A network applies such a set in its own policy, accepting the routes the filter matches or, where the filter is negated, all others. Routes that a route-set contributed can be dropped this way. The mbrs-by-ref and member-of pairing described above also limits which objects join a set. The set owner can restrict to specific maintainers in mbrs-by-ref, and an object's owner can leave the set out of its member-of. However, this does not affect other sets in the hierarchy. Consumers of a set, meaning the operators and tools that resolve it to build filters, also exclude members by means outside RPSL. Some filter-generation tooling and IRR servers offer options to drop named sets during expansion, so that a network can, for example, keep IXP route-server sets out of its filters. Such exclusions are chosen by the party building the filter and apply to a single resolution. They are not published to other consumers.

Missing Exclusion Options None of the existing options gives a set owner a way to exclude an AS number, address prefix, as-set or route-set that was included recursively through (src/mp-)members. An owner can only control the members the object lists directly. Consumers encounter problems such as: A set somewhere in the hierarchy includes a member its owner has no relationship with. Consumers build filters that accept those routes. The set's owner can then make advertisements it is not authorised to make, whether a route hijack (intentional) or a route leak (accidental). The inclusion may be nested many levels down, where the consumer has no direct relationship with the owner that made it, and so no practical way to get it removed. A member intended to be a downstream is instead a peer or upstream. The IRR now shows the including set's owner as that member's transit provider. Filters can then expand massively, even to the whole global routing table. They become too large to program onto devices and too broad to offer useful protection. A member is added whose actions violate a law, a geo-political agreement, sanctions, or a peer or upstream's terms. Peers and upstreams of the including set's owner may now forward traffic for that member. If the including set belongs to a direct peer of the consumer, the two can discuss an alternative between themselves. If the member instead sits many levels down under a peer, that peer usually cannot help, having no relationship with the member itself, and the consumer is left with fragile manual workarounds. The same applies where a peer or upstream already serves the added member directly and a regulation forbids that peer or upstream from serving it via a third party. The excl-members attribute lets a set owner name AS numbers, address prefixes, as-sets and route-sets to exclude when its own set is resolved, including ones an included set brings in. The included set itself is unchanged. Because the attribute is published with the object rather than chosen by the consumer, every resolver that implements this document applies the same exclusions. excl-members does not change how a route is validated against a Route Origin Authorization or an Autonomous System Provider Authorization , or how the roles defined in apply.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology The terms upstream, downstream, peer and transit provider are used as defined in .

The excl-members Attribute excl-members is a new attribute on the as-set and route-set classes. It builds on the src-members attribute defined in . Readers should be familiar with src-members and its motivation before continuing.

The as-set Class On an as-set, excl-members uses almost the same syntax as members (): one or more AS numbers or as-set primary keys. The only difference is that an as-set key MUST be prefixed with a registry name and a double colon, for example EXAMPLE::. This removes the ambiguity of as-set primary keys without a registry scope, described in .

Attribute:: excl-members
Value:: list of ([as-number] or [registry-name]::[as-set-name])
Type:: optional, multi-valued

The route-set Class On a route-set, excl-members uses almost the same syntax as mp-members (, which extends Sections and of ): one or more IPv4 or IPv6 address prefixes, AS numbers, as-set primary keys, or route-set primary keys. An address prefix or route-set key may be followed by a range operator. An as-set or route-set key MUST be prefixed with a registry name and a double colon, for example EXAMPLE::, for the same reason as on the as-set class.

Attribute:: excl-members
Value:: list of ([ipv4-address-prefix-range] or [ipv6-address-prefix-range] or [registry-name]::[route-set-name] or [registry-name]::[as-set-name] or [as-number] or [registry-name]::[route-set-name][range-operator])
Type:: optional, multi-valued

Attribute Validation When an authoritative IRR registry processes the creation or update of an as-set or route-set with an excl-members attribute, it MUST validate the attribute's contents.

Registry Scopes and Duplicate Keys Every reference to an as-set or route-set in excl-members MUST contain a registry scope. AS numbers are globally unique and are written without one. IRR registry software MUST reject an excl-members attribute containing two keys that are identical once their registry scopes are removed:

If this were allowed, the two entries would refer to two different sets, whereas (mp-)members can only hold one AS-EXAMPLE, leaving it ambiguous which set the exclusion refers to. IRR registry software MUST also reject an object where excl-members and src-members contain an identical key with an identical registry scope:

This object would include a member and immediately exclude it again, which is meaningless and likely a mistake. The same key with different registry scopes is permitted, e.g. src-members: RIPE::AS-EXAMPLE with excl-members: ARIN::AS-EXAMPLE.

No Membership, Scope or Existence Requirement IRR registry software MUST NOT require that a key in excl-members is also a direct member of the object being created or updated. excl-members applies to everything reached through the object that contains it, and the object named may be referenced several levels further down. IRR registry software also MUST NOT require the registry scope on an excl-members key to be one it recognises. An authoritative server's content may be mirrored to resolvers that see many more registries. An excl-members entry may name an object that a resolver cannot retrieve, because no such object exists or because that registry is not among those it has data for. Exclusions are matched against during resolution, not during creation of the object.

Resolver Behaviour The excl-members value applies to everything reached through the set that contains it, down the tree. That means a set is resolved under its own exclusions and those of every object on the way to it, from the viewpoint of the set requested by the consumer. A member named by any of the exclusions MUST be ignored by the resolver. Because more than one set may reference the same object, the same object can be excluded on one path and still included through a different path, where that exclusion does not exist. A member that joined a set through mbrs-by-ref and member-of MUST be treated the same as one listed in members or mp-members. On an as-set, an excluded AS number MUST NOT be included. On a route-set, the resolver MUST NOT include such a prefix if there is an excl-members entry that names that prefix without a range operator. The result of resolving a set MUST NOT depend on the order in which an implementation follows references. An excl-members key that names an as-set or route-set contains a registry scope. A key that contains no registry scope, in members or mp-members, MUST be compared against the excl-members key with that key's scope removed. A registry-scoped key in src-members () MUST match a registry-scoped excl-members key exactly, with neither scope removed. Where src-members and members or mp-members on the same object define the same key, once the scope is stripped from the src-members entry, the src-members key MUST be compared against excl-members with both scopes present, and takes precedence over the members or mp-members entry. Where a reference names a set without a registry scope and an exclusion matches it, that reference MUST NOT be followed. The resolver MUST NOT instead resolve that reference in another registry. Doing so could contribute members that would otherwise not have been included.

Matching Address Prefixes and Range Operators An excl-members entry containing address prefix, is compared with each member as written, including any range operator. The address MUST be compared after converting it to the text representation of , so that 2001:DB8:0::/32 and 2001:db8::/32 are equal. The prefix length and the range operator MUST be compared as written. A resolver MUST NOT evaluate range operators when comparing. This means an excl-members entry 192.0.2.0/24^+ excludes a member 192.0.2.0/24^+, but not 192.0.2.0/24, 192.0.2.0/25 or 192.0.2.0/24^24-32, even though some of these are an equivalent notation. A range operator on a route-set key in excl-members is compared in the same way. RIPE::RS-EXAMPLE^+ excludes a src-members reference written as RIPE::RS-EXAMPLE^+, but not one written as RIPE::RS-EXAMPLE.

Exclusions on an as-set When excl-members is populated on an as-set, a resolver MUST NOT follow a reference to any as-set that excl-members names, and MUST NOT include any AS number it names. The exclusion covers members and src-members, on the as-set that contains it and on every as-set reached through it. Consider the as-sets in :

The members of AS-EXAMPLE-A1, accounting for excl-members, are AS64500 and AS64502. AS64501 is not included, because it is listed in both members and excl-members on AS-EXAMPLE-B1. An exclusion also takes effect on the same object. AS64504 is not included either, even though it is a member of AS-EXAMPLE-C1, one level below the object that excludes it. The exclusion applies to everything reached through AS-EXAMPLE-B1. AS64503 is the only member of AS-EXAMPLE-D1, and is not included. AS-EXAMPLE-C1 references that set in src-members as RIPE::AS-EXAMPLE-D1, which matches the excl-members entry on AS-EXAMPLE-B1 exactly, with both registry scopes present.

Exclusions on a route-set When excl-members is populated on a route-set, a resolver MUST NOT follow a reference to any as-set or route-set that excl-members names, and MUST NOT include any address prefix it names. The exclusion covers (mp-)members and src-members on the route-set that contains it and on every route-set reached through it, and members and src-members on every as-set reached through it. Per , a (mp-)members or src-members entry naming an AS number stands for the routes originated by that AS. Where excl-members lists that AS number, a resolver MUST NOT expand such an entry. The resolver does not re-examine the origin of prefixes reached by other references. Consider the route-sets in :

The members of RS-EXAMPLE-A1, accounting for excl-members, are 192.0.2.0/25 and 2001:db8::/33. 2001:db8:8000::/33 is not included. RS-EXAMPLE-B1 scopes its reference with src-members: RIPE::RS-EXAMPLE-C2, which matches the excl-members entry on RS-EXAMPLE-A1 exactly, with both registry scopes present. RS-EXAMPLE-C1 references RS-EXAMPLE-C2 as well, without a scope. That reference is compared against the excl-members entry with the registry scope removed, so it matches and is excluded too. 192.0.2.128/25 is not included. RS-EXAMPLE-C1 lists it as a member, written exactly as the excl-members entry on RS-EXAMPLE-A1. Had RS-EXAMPLE-C1 written it as 192.0.2.128/25^+, or covered it in a 192.0.2.0/24^+ entry, the exclusion would not have matched.

Multiple Paths to a Set The exclusions of each object on the way accumulate as resolution descends. An implementation may therefore have to track several collections of exclusions at once, one for each path it is currently following, rather than a single one for the whole resolution. Consider the as-sets in , in which AS-EXAMPLE-C2 can be reached both through AS-EXAMPLE-B1 and through AS-EXAMPLE-B2:

Resolving AS-EXAMPLE-A1 reaches AS-EXAMPLE-C2 in two ways: Through AS-EXAMPLE-B1 and then AS-EXAMPLE-C1. AS64505 is excluded by AS-EXAMPLE-A1, and AS-EXAMPLE-C2 by AS-EXAMPLE-B1, though AS-EXAMPLE-C2 is not a member of AS-EXAMPLE-B1 itself. This path contributes only AS64503. Through AS-EXAMPLE-B2. Only the exclusion of AS64505 applies here, so the reference to AS-EXAMPLE-C2 is followed. This path contributes AS64504. AS-EXAMPLE-A1 resolves to AS64503 and AS64504. AS-EXAMPLE-C2 is still reached through AS-EXAMPLE-B2. Implementations MUST NOT apply an exclusion to objects other than the object that contains it and those reached through it. If they did, the owner of an included set could add keys to its own excl-members and remove members from unrelated parts of the hierarchy.

Disabling Exclusions in Queries IRR software MAY provide a query option to disable the processing of excl-members. With that option, sets are resolved without applying any exclusions, as software without support for excl-members would. This option helps users to compare results with those from software that does not support excl-members, and debug unexpected resolving results.

IANA Considerations This memo includes no request to IANA.

Security Considerations A resolver that does not support excl-members will not apply exclusions in results. Operators who depend on exclusions should verify that the resolver they use supports the attribute. The presence of the attribute does not indicate correct filtering, as tools using the IRR should be designed to ignore attributes they do not understand (). A set owner cannot verify through the IRR that an exclusion has taken effect for any given consumer. Resolving a set with exclusions costs more than resolving one without. An implementation has to track what is excluded separately for each part of the hierarchy. Combined with circular references, which resolvers must already detect, this can be used to consume resources. Implementations are RECOMMENDED to limit the depth or size of a resolution.

Acknowledgments The authors would like to thank Jeffrey Haas, Nick Hilliard and Job Snijders for their helpful suggestions and review of this document.