[spring] Re: draft-ietf-spring-srv6-security-11 early Intdir review

[Tal Mizrahi <[e-mail]>]

Dear Antoine,

Thanks for the review and comments.
We have revised the document and we believe your comments have been addressed:
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-security/12

Please see some replies below, marked [TM].

Cheers,
Tal.

On Wed, Feb 25, 2026 at 4:18 PM Antoine Fressancourt via Datatracker
<[e-mail]> wrote:
>
> 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?

[TM] Based on this comment and other comments, we have significantly
revised the text that discusses SR domains, trusted domains, and
inter-SR-domain scenarios in Section 4. We believe the updated text is
clear.

>
> 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.

[TM] Indeed, this point was discussed in previous versions of the
document. For example, see the last paragraph of Section 4 of version
00 (https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-security/00/)
However, due to comments we received from the working group, it was
decided that this discussion did not contribute to the clarity of the
document, and it was decided to remove it. We prefer not to add this
discussion to the document at this point.

>
> * 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).

[TM] We believe that the relation between mitigation methods and
attacks is already described in section 7. For example, the fact that
HMAC TLV mitigates modification is already discussed in section 7:
"Using an HMAC in an SR domain can mitigate some of the SR
Modification Attacks (Section 6.2.1)".

>
> * 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.

[TM] We have updated this text, clarifying that encapsulation is a
mitigation method in 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.

[TM] Right. We have reviewed all instances of the word "secured', and
rephrased in one place where we found it was necessary.

>
> * 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.

[TM] Right. Rephrased.

>
> * 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.
>

[TM] Right. Rephrased.

> 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.

[TM] Right. Rephrased.

>
>