[spring] Re: draft-ietf-spring-resource-aware-segments-17 ietf last call Secdir review

["Dongjie (Jimmy)" <[e-mail]>]

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 <[e-mail]>
> Sent: Saturday, April 4, 2026 1:42 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]
> 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.
> 
>