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-06-02
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 telechat comments.
This is a telechat review of -18. A SECDIR Last Call
review of -17 returned Has Issues with four major and four
minor issues. The -18 revision is substantively responsive
to that review and to the other Last Call reviews, and the
security posture of the document is materially improved.
This review credits those changes and then evaluates the
revised text on its own terms. Two normative issues remain
in the security-critical text, along with three minor issues
and several nits.
What -18 resolved:
- Section 8 now requires resource-allocation operations to
use control or management channels with mechanisms for
"authentication, authorization, integrity or
replay-protection" (the disjunction is the subject of
issue (1) below).
- Section 8 acknowledges the Flexible Algorithm threat,
stating that hijack of a Flex-Algo bound to a resource
group compromises resource-isolation correctness, not
just path selection.
- Section 8 adds an admission-control requirement so that
resource-aware SID allocation cannot starve the base SR
forwarding plane.
- Section 8 expands the compromised-node analysis beyond
refusal to allocate, to include overstating available
resources and selectively degrading resource groups.
- Section 7 adds a fail-closed rule: when a node detects
inconsistent resource binding, the impacted
resource-aware SIDs MUST NOT be used for forwarding,
with an error logged and reported.
- Section 3.1 scopes inter-domain links to domains under a
single administrative entity, aligned with the RFC 8402
trust model.
- Section 4 adds provisioning consistency and rollback
language, and a "fully provisioned before use" rule.
These are the right changes. The remaining issues follow.
Result: Has Issues. Two issues (issue (1) may warrant
DISCUSS), three minor issues, and several nits.
Issues:
(1) The principal security requirement is normatively
ambiguous.
Section 8 states that resource allocation, SID-to-resource
association, and distribution of resource-aware SID
information "MUST be done via control or management protocol
channels with proper mechanisms for authentication,
authorization, integrity or replay-protection."
The trailing "or" makes the requirement ambiguous, and this
sentence is the document's principal security requirement,
so the ambiguity is consequential. At least two readings
are available, and both are too weak:
- Read as a four-item disjunction (the default reading of
"A, B, C or D"), a channel providing only one of the
four properties would satisfy the MUST.
- Read more charitably, the sentence requires
authentication and authorization plus either integrity
or replay protection -- which still permits an
authenticated, authorized channel with no replay
protection, leaving it open to replay of stale or
rolled-back bindings.
These four properties are individually necessary and not
interchangeable. Recommend stating them as a conjunction,
for example: "MUST be performed over control or management
channels that provide mutual authentication, authorization,
integrity protection, and replay protection, and SHOULD
provide confidentiality where the channel carries network
topology or resource-capacity information." The
confidentiality clause is included because Section 8
separately states that underlay resource-allocation details
MUST NOT be exposed to third parties; that MUST NOT is
difficult to satisfy if the channels carrying that state are
not afforded confidentiality.
(2) Companion-specification security requirement is SHOULD,
not MUST.
The sentence following the one above states that the
specifications of the control or management plane protocols
for resource-aware segments "SHOULD specify how these
security properties are provided."
This document defers all control-plane and management-plane
mechanics to other documents. Section 4 says the mechanisms
of RFC 8665, RFC 8667, RFC 9085, RFC 9352, RFC 9513, and
RFC 9514 may be reused "with possible extensions," and
points to draft-ietf-teas-nrp-yang for NRP provisioning.
If the obligation on those companion specifications is only
SHOULD, the normative chain breaks at exactly the point
where the security properties required by issue (1) would
actually be realized. The document mandates secured
allocation channels but does not require the documents that
define those channels to specify how the security is
achieved.
Recommend changing SHOULD to MUST.
Minor Issues:
(1) Excess-traffic policy permits silent best-effort
fallback.
Section 7 now handles the binding-inconsistency case with a
fail-closed MUST NOT, which is the correct treatment for the
document's core correctness condition. The following
paragraph, addressing traffic that exceeds the allocated
resources of the resource-aware SID, states: "The options
include: drop the traffic, lower the priority and treat it
in best effort, etc."
Excess-traffic handling is a policing decision rather than a
correctness fault, so a fail-closed rule is not required
here. However, "lower the priority and treat it in best
effort" allows silent degradation of SLA-bearing flows: an
adversary who can induce traffic to exceed an allocation can
cause premium flows to be treated as best effort with no
required signal. Where best-effort fallback is chosen, the
document should require that the event be observable
(counted, logged, or signaled) so that SLA violations are
detectable rather than accumulating invisibly.
(2) Resource-group update atomicity sentence is inverted.
Section 4 states: "An update to a resource group is finished
until all changes to the involved network nodes are
successfully made." As written this is backwards (it
asserts the update is finished before the changes are made).
The intended meaning is evidently "is NOT finished until" or
"is finished only when". Because this sentence defines the
commit semantics of a resource-group update, and partial
provisioning is one of the failure surfaces this document is
trying to close, the inversion should be corrected rather
than left as a nit.
(3) "Techniques need to be developed" sentence contradicts
the surrounding text.
Section 8 retains: "Dynamic attacks of this sort are not
something that networks have traditionally guarded against,
and networking techniques need to be developed to defend
against this type of attack." The very next sentence then
states that the attack "can be prevented" by ingress
policing and careful provisioning, and -18 has added
concrete normative defenses elsewhere in the section
(authentication, authorization, admission control) plus the
fail-closed rule in Section 7. The "need to be developed"
claim is therefore now inconsistent with the document's own
mechanisms. Recommend removing or rewording it to reflect
that the requirements added in -18 address this threat
class, while operational vigilance remains necessary.
Nits:
Section 8 references RFC 9350 generically for the FlexAlgo
threats; the relevant threats (high-priority FAD hijack,
false advertisement of Flex-Algo support) are in RFC 9350
Section 17. A specific section reference would aid the
reader.
Section 8: "an resource group" should be "a resource group".
Section 2: "Resouce group" should be "Resource group".
Section 8: "allocaton" should be "allocation".
Section 8: "managment" should be "management".
Section 7: "diagonosed" should be "diagnosed".
Section 4: "specific nodes.The details" is missing a space
after the period.
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
