Hi Derrell, Thanks again for your review of this draft. We've posted a new revision which incorporated all your comments and suggestions on the security considerations: https://datatracker.ietf.org/doc/html/draft-ietf-spring-resource-aware-segments-18
Please let us know if there is anything missing. Thanks. Best regards, Jie (on behalf of coauthors) -----Original Message----- From: Dongjie (Jimmy) <[email protected]> Sent: Thursday, April 23, 2026 11:27 PM To: Derrell Piper <[email protected]>; [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: RE: draft-ietf-spring-resource-aware-segments-17 ietf last call Secdir review Hi Derrell, Many thanks for your thorough review of this draft and all the suggestions from the perspective of security, they are very helpful. The authors will update this draft accordingly and add more text into the security considerations section in next revision. Also thanks a lot for catching the nits. Best regards, Jie > -----Original Message----- > From: Derrell Piper via Datatracker <[email protected]> > Sent: Saturday, April 4, 2026 1:42 AM > To: [email protected] > Cc: [email protected]; > [email protected]; [email protected] > Subject: draft-ietf-spring-resource-aware-segments-17 ietf last call > Secdir review > > Document: draft-ietf-spring-resource-aware-segments > Title: Introducing Resource Awareness to SR Segments > Reviewer: Derrell Piper > Review result: Has Issues > > 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 <topology, > algorithm> 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 > <topology, algorithm> 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 <topology, > algorithm> 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. > > _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
