Summary

  • A 20 September individual Internet-Draft proposes a Region Identifier inside a ROA and a second validation step that compares it with the region inferred at a router's ingress.
  • The proposal can make a holder's regional intent machine-readable. It cannot make RIR provenance, country, peering site, geofeed, ingress tag and permission to route equivalent facts.

Today a ROA answers a deliberately small question. Has the address-space holder authorised this AS to originate this prefix, at this prefix length? The answer is valuable because it is narrow enough to sign, distribute and validate.

draft-geng-sidrops-regionalized-roa-00 asks whether that answer should carry a second coordinate. Its authors describe an attacker or unauthorised edge node that announces a prefix under the legitimate origin AS from the wrong region. Ordinary ROV can still call that route Valid. Their proposed Regionalized ROA, or R-ROA, would attach a region to the authorization, carry it through an RPKI-to-router extension and let a router return RegionMismatch when the received route appears elsewhere.

That is a serious problem statement. It is also where the bookkeeping becomes political and operational at once: who defines “elsewhere”, and what exactly has been proved when two region labels differ?

One field, three kinds of place

The proposed RegionIdentifier can be an RIR code, an ISO country code or a UN M49 region code. Those are not three spellings of one fact.

An RIR code identifies an administrative certification lineage. RFC 7020 describes RIRs as organizations distributing number-registration responsibility across large regions, and notes that LIRs can operate across more than one region. An ISO code names a state or territory. A UN region groups states. None necessarily describes where a router sits, where a customer is served, where a packet entered an AS or where a prefix may legitimately be announced.

The draft sometimes moves from “source RIR / trust anchor” to “intended region” as though the second were inherent in the first. It is not. A prefix certified beneath APNIC can be used by a network with global transit, remote peering, disaster-recovery sites or an anycast service. The holder may still wish to declare a narrower operating scope. That declaration would be new information supplied by the holder, not geography recovered from the allocation certificate.

This distinction protects the proposal rather than dismissing it. A signed statement of intent can be useful. It becomes unsafe when readers forget that it is a statement.

The router must manufacture the other half

The proposed comparison requires Region_Ctx for each received update. The draft offers three sources: configuration attached to an ingress peer, a BGP community, or correlation with topology and telemetry.

Each can be operationally sensible. Each has its own author and clock. A peering session may terminate in one city while carrying routes learned through remote peering from another market. A Large Community is opaque routing-management data under RFC 8092; its meaning comes from the operator's convention. BGP-LS can describe topology without proving the physical or legal location assigned to every element. A stale interface label can outlive a circuit move.

The draft acknowledges that spoofed or misconfigured peering context produces false positives and false negatives. That admission should shape the validation state. RegionMismatch can accurately mean “the signed declaration and the locally derived context disagree”. It cannot, without additional evidence, mean “hijack proved”.

The evidence chain should therefore retain at least the signed region assertion, its vocabulary and version, the ingress observation, the rule that converted observation into a region, the route and path received, the local policy action, the alternative route selected, and the reachability result. Compressing them into one red icon would make later correction almost impossible.

A signed geofeed signs the publisher, not the ground

For deployments that cannot change RPKI objects immediately, the draft permits an enhanced local database assembled from delegated statistics and geolocation data. It points to RFC 9632.

RFC 9632 is more cautious than the shorthand “RPKI-signed location metadata” suggests. Its optional authenticator can prove that a key authorised for the address range signed a geofeed. Its security section still advises consumers to cross-check other sources and warns about trust in third-party processing. A signature proves custody and origin of the assertion. It does not send a surveyor to the site.

That makes the out-of-band option a local policy database, not a substitute ROA. The difference matters for liability and rollback. If a bad geofeed-derived row causes a valid route to be dropped, the operator needs to know which local transformation created the row and how to withdraw it without waiting for a global certification change.

Compatibility needs a protocol, not an adjective

The draft sketches either a new RTR PDU or an extended prefix PDU and says older routers will ignore the region or continue ordinary ROV. RFC 8210, however, negotiates protocol versions and defines an unsupported PDU type as a fatal error. The proposal does not yet spell out a complete negotiation, downgrade and mixed-cache procedure for both wire designs.

That is normal for version 00. It is also why “full backward compatibility” should remain a hypothesis until there is an encoding, state machine and interoperability test. A region feature that disappears silently on downgrade creates a different operational risk from one that terminates a session. Both need visible receipts.

Keep the last decision local

The draft recommends local policy: hard drop, a substantial LOCAL_PREF penalty, or alarm and logging. This is its most important restraint. The signed object can provide evidence; the receiving network still chooses the consequence.

The safest first implementation would preserve that hierarchy. Begin with an alarm state whose provenance can be inspected. Measure how often it catches a known unwanted announcement and how often legitimate anycast, remote peering, recovery and transit arrangements disagree with the declared region. Add preference changes only where an operator has alternative paths and a rollback rule. Treat hard drop as a separately justified policy, not as the definition of RegionMismatch.

The draft has identified a real gap in origin-only validation. Its next task is not to make geography sound cryptographic. It is to specify who may assert each kind of place, how the vocabularies compare, how disagreements expire and how running networks prove that the additional signal helps more often than it harms.

Sources