Subject: [spring] draft-ietf-spring-srv6-security-11 early Intdir review
From: Antoine Fressancourt via Datatracker <[email-masked]>
To: <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Wed, 25 Feb 2026 06:18:25 -0800
List-Id: "Source Packet Routing in NetworkinG (SPRING)" <spring.ietf.org>

Document: draft-ietf-spring-srv6-security
Title: Segment Routing IPv6 Security Considerations
Reviewer: Antoine Fressancourt
Review result: Almost Ready

I am an assigned INT directorate reviewer for
draft-ietf-spring-srv6-security-11. These comments were written primarily for
the benefit of the Internet Area Directors. Document editors and shepherd(s)
should treat these comments just like they would treat comments from any other
IETF contributors and resolve them along with any other Last Call comments that
have been received. For more details on the INT Directorate, see
https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

Based on my review, if I was on the IESG I would ballot this document as
DISCUSS.

I have the following DISCUSS level issues:

* Throughout the document, the (loaded) term "domain" is used while its
definition for the document is a bit unclear (at least to me). The document
refers to RFC 8402 which defines a SR domain as:
        "the set of nodes participating in the source-based routing model.
        [...] some deployments may wish to subdivide the network into multiple
        SR domains, each of which includes one or more protocol instances. It
        is expected that all nodes in an SR domain are managed by the same
        administrative entity."
Yet, quickly in the document it is mentioned that inter-domain segment routing
is out of scope of the document: is this explicitly excluding inter-SR domain
run by the same administrative entity? Later in the document, it is mentioned
that segment routing runs in a Trusted domain: is this trusted domain broader
than a SR domain? Encompassing two SR instances run by a same administrative
entity?

I think the definition / relationship between SR domain, trusted domain and
administrative domain should be made clearer in the text, even more so since
this topic is often debated in the SPRING WG.

The following are other issues I found with this document that SHOULD be
corrected before publication:

* In Section 4, the document is making a distinction between On-path and
Off-path attackers. I think an additional level of refinement should be added
regarding those attackers regarding whether the attacker is a rogue node
participating in the SR domain / instance or not. The major difference in this
regard is that a rogue node may have access to cryptographic material that is
out of reach for an observer of the traffic. This is particularly interesting
to cover attacks on the integrity of the SR header and potential modifications
of the HMAC.

* In section 6, the document should mention potential mitigation mechanisms and
a level of criticality to the attacks being described. For instance, packet
modification attacks can be mitigated by the use of the HMAC TLV (at least
partially).

* In section 7.1.2, the document mentions that SRH packet might be only
transiting a domain. First, I think that the possibility for a SR domain to be
non-continuous should be clarified in the definition. Besides, I would expect
the document to give clearer directions with regards to the use of
encapsulation to cover this case.

* In section 7.3, and in other places in the document, the term "secured" is
used but should be clarified. For instance, I would have explicitly stated that
"The integrity of the SRH can be protected by...". It may seem like nitpicking,
but I think it is important to be clearer about whether integrity, authenticity
or confidentiality is protected in the document.

* In section 7.4, the document mentions attacks on the O-flag. It should
clearly state that the O-flag is in scope of the HMAC TLV, which restricts the
number of potential attackers in case this TLV is used.

* Section 8 of the document should be clarified in writing.
For instance, in the first paragraph of section 8.1, it is mentioned that:
        "[...] its destination address changes constantly and the real
        destination address is hidden. [...]".
The destination address changes along the path, but this change occurs at SR
nodes (possibly not at every node), so "constantly" seems misleading. Besides,
the destination address can be determined from the last segment in the SID
list, which is not hidden from a security / cryptographic perspective.

In the second paragraph of section 8.1, the text mentions the difficulties of
filtering SRv6 packets if there has been an encapsulation at the SR ingress
node. Section 3.5.2.4 of RFC 9288 mentions that:
        "Blocking packets containing Routing Headers of Routing Type 4 (SRH)
        will break Segment Routing (SR) deployments if the filtering policy is
        enforced on packets being forwarded within an SR domain."
This advocates for a deployment of filtering policies at transit routers. The
document would benefit from a mention of RFC 9288 at this point or of a
clarification of the advised policy associated with the filtering of SR traffic
inside the SR domain.