Reviewer: Derrell Piper Review result: Has Issues Date: 2026-04-03 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: This document extends Segment Routing (SR) by associating existing SIDs -- both SR-MPLS Adj-SIDs and Prefix-SIDs, and SRv6 Locators and SIDs -- with preallocated subsets of network resources (bandwidth, buffers, queues, scheduling weights). These "resource-aware SIDs" retain their original forwarding semantics and add the additional semantics of identifying which resource partition a packet should use. The mechanism is intended to support network slicing and SR policies with dedicated-resource treatment beyond what DiffServ traffic classes can provide. No new SID types are defined. No new wire formats are defined. All control-plane and management-plane extensions needed to distribute, authenticate, and authorize resource-aware SID bindings are deferred to other documents. One vendor implementation is reported (Huawei). The security-sensitive contribution of this document is not a new packet format or parser surface. It is the conversion of a SID into an entitlement token: a SID now encodes not just a forwarding instruction but a claim on a privileged subset of underlay resources. The document assumes a centralized controller, allows management-plane or distributed-control-plane association of SIDs to resource groups, requires that packet-to-resource-group association be aligned across participating nodes, and says nodes may advertise resource-group identifiers, topology/algorithm associations, resource-aware SIDs, and TE attributes. Then it pushes the actual protocol details out of scope. That makes the integrity, authenticity, and authorization of the SID-to-resource binding the central security question. The current Security Considerations section identifies one significant threat (SLA-targeted disruption with commercial consequences) and one useful requirement (underlay details MUST NOT be exposed to third parties), but does not provide the normative security requirements needed to protect the mechanism it introduces. Result: Has Issues. Four major issues, four minor issues, and several nits are described below. Major Issues: (1) Missing security requirements for resource-allocation operations. The document describes resource-aware SID creation and SID-to-resource binding via centralized controller provisioning, local configuration, and potentially distributed signaling. It references NETCONF/YANG, BGP SR Policy [RFC9830], and PCEP [RFC8664] as controller-to-node interfaces. Section 3 requires (MUST) that resource-group support and packet-to-resource-group association be aligned across participating nodes. Section 3 further says that nodes may advertise the resource-group identifier, the associated topology and algorithm, the resource-aware SIDs, and a set of TE attributes, and that the mechanisms of RFC 8665, RFC 8667, RFC 9085, RFC 9352, RFC 9513, and RFC 9514 can be reused "with possible extensions," with details out of scope. However, the document specifies no authentication, authorization, integrity, or replay-protection requirements for any of these operations. It does not state who is authorized to create resource-aware SIDs, how a node verifies that a controller request to allocate resources is legitimate, or what security properties the companion signaling and provisioning mechanisms must provide. The base SR trust model (RFC 8402 Section 8) assumes a trusted domain and boundary filtering. BGP SR Policy (RFC 9830) similarly scopes itself to a trusted SR domain. Existing SRv6 security guidance (draft-ietf-spring-srv6-security) recommends authenticated and encrypted controller channels and secured management protocols. This document inherits those assumptions rhetorically but never turns them into requirements for resource allocation and resource-group state distribution. Because compromise of the controller or its southbound channels enables selective SLA sabotage at domain scale -- not just path manipulation, but reallocation of resources across all affected links -- the Security Considerations section should include normative statements requiring at minimum: (a) Mutual authentication between controllers and nodes for resource allocation operations. (b) Authorization enforcement for which entities (controllers, network management systems, distributed peers) may create, modify, or delete resource-aware SID bindings and resource-group associations. (c) Integrity and replay protection for advertisements of resource-group identifiers, resource-aware SIDs, and associated TE attributes. (d) Confidentiality protection (SHOULD or MUST) for controller-to-node and management-plane channels that carry resource allocation state, given that this state reveals the topology and capacity of premium resource partitions. (e) A general requirement that companion specifications defining the actual signaling and provisioning mechanisms MUST specify how they satisfy these security properties. (2) Missing fail-safe behavior and freshness requirements for resource-group state. Section 3 states that resource-group support and the information to associate packets to a resource group MUST be aligned among the network nodes in that resource group. This is a strong requirement with no specified mechanism to verify alignment, detect inconsistency, or handle failure. This mechanism introduces a state-consistency requirement that is stricter than traditional SR forwarding. Inconsistent resource-group state does not merely degrade efficiency; it violates the fundamental contract of resource isolation. Delivering a packet with incorrect resource treatment is a correctness failure, not a soft degradation. This is a departure from typical routing behavior, where forwarding a packet via a suboptimal path is preferable to dropping it, and it should be explicitly called out. The document does not specify what a node should do when: - It receives a packet bearing a resource-aware SID for a resource group it does not recognize. - It detects inconsistent resource-group state between its local configuration and control-plane advertisements. - Resource-group advertisements are stale, partially rolled out, or withdrawn. - A peer node advertises resource-group capabilities that cannot be independently verified. Several concrete failure scenarios illustrate the risk: - Partial rollout: some nodes along a path recognize a resource group while others do not, resulting in inconsistent SLA enforcement hop by hop. The ingress believes the path has dedicated-resource treatment; transit nodes silently forward via best-effort. - Split-brain controller state: different controllers (or a controller and local configuration) assign different resource semantics to the same SID, so nodes along the same path disagree about which resource partition a packet belongs to. - Stale state replay: decommissioned resource bindings are reintroduced (via replay or rollback), mapping traffic to resource partitions that no longer exist or have been reassigned. In all these cases, silent fallback to best-effort forwarding is the operationally tempting default and the worst outcome from a security perspective: the packet still arrives, the SLA quietly degrades, and the failure is only visible through telemetry after the fact. For a mechanism whose entire value proposition is resource isolation and dedicated-resource treatment, the Security Considerations section should include a normative statement that nodes MUST NOT silently apply best-effort or arbitrary treatment when resource-group state is missing, inconsistent, or unverifiable. The specific required behavior (drop, alarm, well-defined fallback with notification) may be left to implementation, but the prohibition on silent degradation should be unambiguous. The compromised-node analysis in Section 7 is also too narrow. The current text says a compromised node "may choose not to allocate the necessary resources." That is the polite failure mode. Given that nodes may advertise resource-group identifiers and TE attributes, a malicious node could also: - Overstate available resources to attract traffic it will then under-serve. - Selectively degrade specific resource groups to target specific tenants or SLA classes. - Advertise participation in a resource group without actually allocating the resources, making the MUST-align requirement unverifiable. These threats follow directly from the mechanism the document defines and should be acknowledged in the Security Considerations section, even if complete mitigation requires mechanisms beyond this document's scope. (3) Incomplete scoping of trust assumptions at domain boundaries. The document allows multiple resource-aware BGP PeerAdj SIDs on inter-domain links (Section 2.1) but does not clarify whether "inter-domain" means same-provider multi-AS deployment (consistent with the SR/SR Policy trusted-domain model) or something broader. The base SR trust model (RFC 8402) and BGP SR Policy (RFC 9830) explicitly scope themselves to a single provider's network, even across multiple ASes. Because the document mentions inter-domain links without qualification, the text reads looser than the inherited trust model actually supports. The document should either explicitly limit inter-domain resource-aware SID applicability to same-provider trusted deployments, or state the trust and authorization assumptions required for resource allocation across external peer boundaries. (4) FlexAlgo dependency and threat amplification. The document ties resource-aware SIDs to tuples and explicitly references Flexible Algorithm (RFC 9350) as a control-plane mechanism for distributing resource-aware SIDs and associated topology. RFC 9350 Section 17 identifies specific threats: an attacker can hijack a Flex-Algorithm by advertising a high-priority Flexible Algorithm Definition (FAD), or can falsely advertise participation in a Flex-Algorithm it does not actually support. Because this document binds resource-aware forwarding semantics to a tuple, a successful FlexAlgo spoofing attack does not merely change paths; it can redirect traffic away from its allocated resource partition entirely, or cause traffic to be forwarded through nodes that have not actually allocated the corresponding resources. This is a direct amplification of the FlexAlgo threat in the resource-aware context. The Security Considerations section should acknowledge the dependency on FlexAlgo integrity and reference the specific threats identified in RFC 9350 Section 17, noting that FlexAlgo spoofing compromises not just path selection but resource-group correctness. Minor Issues: (1) Resource exhaustion and admission control. The document acknowledges indirectly that more resource groups mean more SIDs, more locators, and more node state (Sections 2.1, 2.2, and 6). It advises operators to plan resource groups carefully and suggests rate-limiting IGP updates when available resources change after instantiating new resource-aware SIDs. These are useful operational cautions, but they are not normative safeguards. The document does not discuss admission control for resource allocation: what prevents a controller (compromised or misconfigured) or a node with local configuration authority from allocating resource-aware SIDs that consume all available resources on a link or node, thereby starving other services including base SR forwarding. A statement recommending or requiring that base forwarding-plane availability cannot be exhausted by resource-aware SID allocation would strengthen the security posture. (2) PHP interaction with resource selection. Section 2.1 recommends disabling Penultimate Hop Popping (PHP) when egress-node resource allocation must be determined from the outer label. The alternative is to infer the resource group from the inner service label. This is a security-relevant design choice: it determines where resource-selection authority resides and what metadata the egress node trusts for resource-group inference. A brief discussion of the security tradeoff between these two approaches would be appropriate in the Security Considerations section. (3) Information leakage beyond path disclosure. The document correctly states that underlay network details MUST NOT be exposed to third parties. Base SR (RFC 8402) and SRv6 (RFC 8754) already require boundary filtering and note that segment routing headers can reveal topology and traffic flows if observable inside the domain. In the resource-aware design, the leakage is more sensitive: observable labels or locators can reveal not just where packets go, but which paths correspond to premium or partitioned resource pools. For SRv6, the resource-aware Locator is routable and visible in the IPv6 destination address, making the resource-group association directly observable to any on-path entity. The Security Considerations section should distinguish path-disclosure risk from resource-entitlement disclosure risk, as the latter is commercially and operationally more sensitive. (4) Security requirements not flowed to companion specifications. The document defers all control-plane and management-plane protocol extensions to other documents. Section 3 says the mechanisms of RFC 8665, RFC 8667, RFC 9085, RFC 9352, RFC 9513, and RFC 9514 can be reused "with possible extensions to improve the efficiency and scalability," with details out of scope. The reference to draft-ietf-spring-srv6-security provides useful baseline guidance, but that document addresses generic SRv6 threats, not the resource-binding-specific threats introduced here. The document should state that companion specifications defining IGP extensions, BGP-LS extensions, PCEP extensions, or YANG models for resource-aware SID distribution and resource-group advertisement MUST address the authentication, authorization, integrity, and freshness requirements for the state they carry. Without this requirement, implementers of the companion mechanisms have no obligation to consider the security properties this document needs. Nits: Section 6: "Althougth" should be "Although". Section 6: "paradigmn" should be "paradigm". Section 2.1, fourth paragraph: "the an IGP Adjacency Segment" should be "an IGP Adjacency Segment". Section 2.1, fourth paragraph: "the IGP-Prefix Segment (Prefix-SID), and the IGP-Node Segment (Node-SID). It also introduces the BGP Peer Adjacency Segment (PeerAdj SID)." The use of "the" before each SID type is inconsistent with RFC 8402 usage and reads awkwardly. Suggest removing "the" before each type or restructuring the sentence. Section 2.1, sixth paragraph: "For one IGP prefix, multiple resource-aware prefix-SIDs may be associated with the same tuple but different resource groups, then an additional control plane distinguisher needs to be introduced" is a run-on sentence. Suggest splitting at "then". The informative reference to draft-ietf-spring-srv6- security points to -10 (January 12, 2026). The current revision is -13 (March 31, 2026), which incorporates changes from WGLC that ended February 16, 2026. The reference should be updated. Section 7: The sentence beginning "Dynamic attacks of this sort are not something that networks have traditionally guarded against" and concluding that "networking techniques need to be developed to defend against this type of attack" is unusual for a Standards Track document. Acknowledging that defenses do not yet exist for a threat the document itself introduces is a transparency credit, but it raises the question of whether the document should proceed to Standards Track before those techniques are at least identified. At minimum, the document should state what security properties those future techniques must provide, rather than leaving both the techniques and their requirements unspecified.