RPSL Registry Scope Stops After One Hop

Summary

The GROW draft’s src-members attribute binds an immediate RPSL set reference to a named IRR registry, but the registry restriction deliberately does not cascade through later recursive lookups.
During gradual adoption, scope-aware and legacy consumers can derive different policies from one valid object; operators need a resolution-provenance receipt and a reviewed result diff before treating either output as deployable authority.

A route-policy build can fail while looking perfectly deterministic. The input says RS-FIRST. The compiler returns a list of prefixes. The list has a timestamp, a count and perhaps a green check beside it. Yet none of those facts answers the question that matters when two registries contain the same set name: which object did the resolver choose at each step?

That missing question is the subject of draft-ietf-grow-rpsl-registry-scoped-members-00. The Internet-Draft adds src-members to RPSL as-set and route-set objects. A reference such as RIPE::AS-EXAMPLE identifies both the set’s primary key and the registry in which the resolver should find it. That is a meaningful improvement over a bare name. It is not an end-to-end provenance chain.

The distinction is easy to miss because the syntax looks like a namespace. It is better understood as a lookup instruction with deliberately local reach.

The ambiguity exists inside ordinary recursion

RPSL sets can contain AS numbers or prefixes directly. They can also contain other sets, which may contain further sets without a fixed depth. Internet Routing Registries are separate repositories, and their primary keys are not globally unique. A server that mirrors several registries may therefore hold more than one object named AS-EXAMPLE or RS-SECOND.

The draft describes two bad results. A resolver can select an object from a registry other than the one the operator intended, producing unintended routing policy. Or it can fail to find the intended object and omit routes that should have been accepted. The draft says the first class can contribute to route leaks or hijacking and the second can disrupt reachability. Those are the document’s general risk statements; revision 00 does not establish a new named incident or quantify deployment prevalence.

Existing RPSL mechanisms did not fully solve the cross-registry problem. Hierarchical set names provide authorization structure within a registry. External-repository notation exists elsewhere in RPSL, but the draft explains that the notation is not supported in the existing set-member fields. src-members brings an explicit source prefix into the attributes used for membership.

For a scope-aware resolver, the first rule is clear. Include values in src-members, and for a set reference match both the registry name and the primary key. If the resolver does not know the named registry, no set matches. A quiet fallback to some unqualified copy would undo the assertion the author made.

Then comes the crucial limit. Once the chosen child set is opened, its own references are resolved according to their own attributes. They may contain another qualified src-members reference. They may instead contain an old members or mp-members value, in which case the resolver’s existing source-selection algorithm returns. The parent’s registry prefix does not cascade.

The same rule applies to an initial query parameter. Software must offer a way to restrict the root lookup to a registry, but that restriction must not pin every descendant lookup to the same registry. A command that starts with RIPE::RS-FIRST is therefore not evidence that every object in the expanded policy came from RIPE.

Compatibility creates two legitimate readers

The draft does not replace members and mp-members. It assumes a gradual transition in which old software remains in service and old objects remain unconverted. An authoritative registry receiving src-members must verify that every value, once its registry prefix is removed, is also present in the legacy fields. That supplies a compatibility projection for consumers that do not understand the new attribute.

Where the user provides src-members and omits both legacy fields, authoritative software is recommended to generate the appropriate legacy values by stripping the prefixes. It must not overwrite legacy attributes that the user actually submitted. A non-authoritative mirror must not manufacture those values. Most importantly, software must not infer src-members from an unscoped legacy reference. The missing registry is the very information the new attribute exists to add.

This gives one valid RPSL object two readings. A modern resolver sees RIPE::RS-SECOND and chooses the object from RIPE. A legacy resolver sees RS-SECOND and applies its own registry preference or search behavior. Validation proves that the stripped name is present in both representations. It does not prove that both readers will select the same object.

The draft contains a revealing constraint. src-members cannot include RIPE::AS-OTHER and ARIN::AS-OTHER together, even though the qualified strings refer to different objects. Stripping both values would produce the same legacy key, which the old representation cannot express twice without ambiguity. Compatibility therefore limits what the more precise syntax may say.

That is a reasonable engineering trade. It also means that “object accepted by the registry” is not the same claim as “all deployed consumers will derive the same policy.”

The final list has discarded the decision path

Suppose two compilers return 8,000 prefixes. Equal counts prove little. One build may have selected the intended child at the first scoped hop and an unintended namesake at a deeper unscoped hop. Another may have stopped when a registry was unknown. A third may have hit a recursion-size limit. The resulting counts can converge while individual members differ.

Even exact equality of the final member set is only a partial result. The build may depend on different registry snapshots, object versions or fallback paths. That difference can surface at the next refresh. A reproducible policy decision therefore needs more than the exported list.

The appropriate evidence object is a resolution-provenance receipt. It begins with the root key and any registry restriction supplied by the caller. It records the resolver implementation and version, whether src-members support was enabled, the registries visible to the resolver and a verifiable snapshot, serial or content hash for each source.

Every recursive edge then receives a record: parent registry and key, attribute used, child reference exactly as written, explicit or implicit source selection, selected registry and key, and a hash of the retrieved object. Unknown registries, absent objects, collisions, cycles, depth limits and size limits are outcomes, not log noise to be discarded.

The receipt should preserve two output hashes during migration. One represents the scope-aware expansion. The other represents the view produced under the actual legacy behavior still present in the operator’s toolchain. Store their exact set difference, not merely their member counts. If the difference is approved, attach the reviewer, reason, expiry and rollback authority.

Finally, bind the resolved set to the policy compiler version, normalization and filtering rules, generated configuration hash, change record and deployment target. That last step prevents a common audit substitution: proving how data was fetched while leaving unproved which compiled artifact was installed.

This is evidence, not a new source of truth

A receipt cannot make a weakly authenticated IRR object authoritative. It does not prove that an AS originates a prefix, validate a commercial relationship or replace RPKI. It does not require operators to publish confidential policy, credentials or complete router configurations. Object hashes, source identifiers, decision roles and result differences can make the path inspectable without exposing those secrets.

Nor should a dual-resolution difference automatically condemn the modern or legacy output. The scoped reference may correctly repair an old ambiguity. The legacy consumer may still be the software that will generate production filters somewhere else in the change chain. The difference is a decision trigger: identify the affected consumers, decide which result is intended, plan the migration and preserve a rollback.

The draft’s security section also keeps two familiar recursion hazards in view. Circular references must be detected. Depth or result-size limits are recommended to constrain resource use. Those settings belong in the receipt because changing either can change the compiled policy without changing a single RPSL object.

src-members is valuable precisely because it lets an author say more than an unqualified set name. Governance fails when an operator records less than the resolver knew. A registry prefix repairs one lookup. Accountability begins when the whole expansion path remains available after the prefix has done its work.

RPSL’s Registry Prefix Stops After One Hop; the Policy Does Not

Why it matters

Summary

The ambiguity exists inside ordinary recursion

Compatibility creates two legitimate readers

The final list has discarded the decision path

This is evidence, not a new source of truth

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing