Summary

  • draft-ietf-spring-srv6-security-16 defines an SRv6 trusted domain by the boundary-filtering assumption being in force. It calls that domain logical and operational, not physical.
  • The draft expressly allows multiple SR instances under the same administrative entity to remain distinct. A shared owner, site or backbone label is therefore not evidence of common trust.
  • Boundary enforcement can fail open through erroneous rule changes or hardware limits. Filtering only for an SRH is insufficient because SRH is optional for SID processing and may appear in transit traffic.
  • A trusted-domain boundary manifest and enforcement receipt should bind membership, ranges, keys, intended and installed rules, capacity and negative tests. This is Daniel Kade’s proposal, not an IETF requirement.

The perimeter that disappeared in PowerPoint

Imagine two carriers becoming one company. Each had built an SRv6 estate with its own SID plan, controllers, key material, operations team and edge policy. On the first integration slide, the two estates are placed beneath the same corporate name. Six months later, an engineer notices a filter between them and asks why “our own traffic” should still be treated as external.

There is no need to invent a malicious actor to see the risk. The consequential move is semantic: an ownership change is being used to rewrite a security classification. If the filter is removed, a node authorized in one estate may gain a path toward SIDs in the other. The change may be described as simplification even though no evidence shows that membership rules, address ranges, control-plane authorities or key domains were unified.

Revision 16 of Segment Routing IPv6 Security Considerations gives this problem unusually direct language. Its trusted domain is an SR domain in which the boundary-filtering assumption from RFC 8402 is in force. It is a logical and operational construct, not a physical boundary. Hosts on the same physical network are not members unless they have explicitly been brought under its controls.

The draft goes further: several SR instances can sit under the same administrative entity while remaining logically or operationally distinct. Deployments that cross those trusted domains are outside the document’s threat-model scope, and a source in another trusted domain is treated as external for that model.

That sentence prevents an organizational chart from becoming a security credential. The operator’s name is not the perimeter. The controls are.

Last Call is a process state, not a deployment fact

The IESG opened Last Call for revision 16 on 3 September 2026 and requested comments by 17 September. At the 9 September research cutoff, Datatracker still described an active SPRING working-group Internet-Draft intended for Informational status. It recorded no telechat date and also showed that a revised text was needed for an issue raised during working-group Last Call.

Those coordinates matter because this article uses the document as current evidence, not settled law. The draft says it defines no new security protocol or extension. A Last Call announcement does not make it an RFC, certify an operator, or prove that any network has applied its advice.

The stable baseline comes from RFC 8402. Segment Routing operates by default within a trusted domain, and traffic must be filtered at domain boundaries. RFC 8402 also exposes the power being delegated: a node that imposes a segment list or SRH is assumed to be allowed to do so. That assumption is practical only while membership and boundary enforcement remain accurate.

An acquisition, outsourcing contract or controller consolidation may change administrative responsibility without changing those technical facts. Conversely, two divisions can deliberately unify their controls before the legal paperwork catches up. Governance must therefore record the operational act, not infer it from corporate timing.

Trust is a verb performed at every edge

The draft does not treat “trusted” as a flattering label. It warns that perfectly crafted filters must survive at every edge. A mistaken removal or adjustment can permit inbound or outbound leakage. Some platforms may not have enough rule capacity, complexity support or protocol capability to express the intended controls. The result is a fail-open condition: attacks expected to require an internal position can become feasible from outside when the systems defining the boundary stop enforcing it.

This gives a trusted domain at least three independent states.

First is declared membership: which nodes, controllers, sources and roles belong. Second is intended enforcement: which ingress, egress and node-local rules should make that membership meaningful. Third is observed enforcement: what the installed hardware can actually match and drop at the current revision and load.

A design document proves the first two only imperfectly. A configuration commit proves that someone requested a change. Neither proves that every relevant edge accepted the rule, retained it after a restart, had enough table space, or counted the negative test as expected.

The distinction becomes sharper during integration. One estate may use a dedicated SID prefix while the other uses a more complicated allocation. One may encapsulate at ingress; the other may accept packets differently. One platform may share finite access-control resources among routing, VLAN and other functions. Calling both “ours” does not make these differences vanish.

Looking for an SRH is not the boundary

A simple migration plan might say: drop SRH at the seam and remove the rule once the networks share ownership. Revision 16 explains why SRH presence is the wrong universal test.

An SRH is optional for SID processing. At the same time, a packet carrying an SRH may merely transit a domain rather than target it. A blanket presence check can therefore miss relevant traffic and damage legitimate transit. The draft instead ties external-attack mitigation to address and origin relationships: at ingress, drop outside traffic destined to an internal SID; at an SRv6-enabled node, drop traffic to a locally instantiated SID when the source lies outside the SR domain.

This is not just a syntax distinction. It requires a trustworthy inventory of SID ranges, source ranges, domain edges and instantiated functions. RFC 9602’s dedicated SRv6 SID prefix can simplify edge filtering. The draft notes that other prefix choices can complicate policy and increase route-leak or human-error risk. The correct rule follows the actual addressing design, not the new letterhead.

Encapsulation adds another control. An ingress can impose a fresh outer IPv6 header and SRH, so forwarding inside the domain does not depend on fields supplied by an untrusted source. The egress can prevent internal segment information from escaping. Yet the draft is careful: encapsulation complements boundary filtering; it does not replace it. A packet that already satisfies the domain’s filtering criteria remains a different problem.

One building can contain two key domains

Cryptography is equally easy to misread as a merger certificate. RFC 8754 defines an optional HMAC TLV for selected SRH fields. Revision 16 notes that manual pre-shared-key operations may tempt teams to reuse one key across nodes. It says the same key should not be used for different trusted domains, including domains on the same node.

That last clause is the operational test. Physical consolidation can be complete while trust separation remains correct. If two instances retain different authorities, their key domains should remain distinct even when a single chassis hosts both.

HMAC also has bounded meaning. It can protect the segment list and related fields from some modification, but it does not make every key holder institutionally authorized for every path. A compromised legitimate node with the key remains an internal attacker in the draft’s model. An internal actor without the key may still replay a captured valid SRH and HMAC during the key’s lifetime. Key possession is evidence about a cryptographic relation, not a complete authorization decision.

Enterprise-wide key reuse destroys that distinction. It makes a shortcut look like unification and complicates later separation. The fact that a shared key technically verifies a packet is not proof that the two estates should have trusted one another.

Record the boundary that actually exists

The missing operator artifact is a trusted-domain boundary manifest and enforcement receipt. It can remain outside the protocol. Its purpose is to stop six different records from being compressed into one “internal” flag.

The manifest gives the domain a versioned identifier. It names admitted nodes and roles, ingress and egress points, SID and permitted source ranges, encapsulation points and controller authorities. It records key-domain identifiers without publishing key material. It also names explicit crossings to other domains, the policy owner for each crossing, its expiry and the reason it exists.

The enforcement receipt is created at a change. It joins the approved intent to the rules each device reports as installed, the hardware capacity available, relevant counters, a negative test from outside the domain, a permitted-path test from inside, and any exception or partial failure. A later topology, software, prefix, role or key change either produces a new receipt or makes the old one stale.

No green badge should claim “one trusted domain” merely because all devices share a cost centre. A useful badge would say something narrower: this named domain revision was tested at these edges against these ranges, on these builds, at this time, with these unresolved exceptions.

The Policy Mirror asks where effective rules are actually written. In this case they are distributed across membership, ranges, filters, encapsulation and keys. Running-Code Primacy demands evidence that those rules execute, not only that an architecture document contains them. Reality, Not Advocacy keeps the conclusion bounded: the IETF draft does not accuse a deployment or solve inter-domain SRv6. It supplies the reason operators must not confuse common ownership with common trust.

Sources