MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Derrell Piper via Datatracker <noreply@ietf.org>
To: <secdir@ietf.org>
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: 
 <177523809266.288026.7918012198710283231@dt-datatracker-9dc8fdd9f-qcdj9>
Date: Fri, 03 Apr 2026 10:41:32 -0700
Message-ID-Hash: BXRDL4Z4CQM4YLL7HNCP2ATKL4BQDJIO
CC: draft-ietf-spring-resource-aware-segments.all@ietf.org,
 last-call@ietf.org, spring@ietf.org
Reply-To: Derrell Piper <ddp@electric-loft.org>
Subject: =?utf-8?q?=5Bspring=5D_draft-ietf-spring-resource-aware-segments-17_ietf_las?=
	=?utf-8?q?t_call_Secdir_review?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/spring/jLtobteM1p12BH2YtLeg3gwtH5E>

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.