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

[Tal Mizrahi <[e-mail]>]

Hi Christian,

Thanks for a very detailed review.
We have posted a revised version:
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-security/12

Please see some replies below.

Cheers,
Tal.

On Sun, Feb 15, 2026 at 1:53 AM Christian Huitema via Datatracker
<[e-mail]> wrote:
>
> Document: draft-ietf-spring-srv6-security
> Title: Segment Routing IPv6 Security Considerations
> Reviewer: Christian Huitema
> Review result: Has Nits
>
> This document is titled "Segment Routing IPv6 Security Considerations", which
> is rather bland, but the document itself is anything but bland. It is a
> methodical evaluation of SRv6 security issues, starting with a well
> constructed threat model, going all the way to the evaluation of attacks and
> existing mitigations, some of which it finds wanting. It does propose practical
> improvements. It is great to see this kind of work coming from the
> routing area, and my first reaction is to applaud!
>
> The threat analysis follows a methodical progression: categorization of attackers,
> listing of assets, listing of attacks and analysis of mitigations. They consider 5
> types of attackers, on path or not, internal or external, and with access to
> the control plane. The listing of assets is good, although I would add something
> about the privacy of end to end users. I would apply the same remark to the
> analysis of attacks. It is rather exhaustive, except maybe for the possible use of SRH
> options as a way to track end users or their behavior.

[TM] Right. Based on your comment we have revised Section 6.2.2.3,
adding the privacy aspect. We have also updated the text in 7.1.3,
which now also addresses this issue.

>
> I think the meat of the document is in the analysis of mitigations. I hope that
> deployments of SRV6 pay attention to it, and in particular the robust discussion of
> Trusted Domains and Filtering in section 1.1, which points out that it might
> be insufficient to trust access filtering at the domain borders to ensure safety
> of operations. To quote:
>
>    Practically speaking, this means successfully enforcing a "Trusted
>    Domain" may be operationally difficult and error-prone in practice,
>    and that attacks that are expected to be unfeasible from outside the
>    trusted domain may actually become feasible when any of the involved
>    systems fails to enforce the filtering policy that is required to
>    define the Trusted Domain.
>
> This is typical of the seriousness of this document, which does not attempt to brush off obvious
> issues with the idea of "limited domains". Not a really new concept, the old polar bear
> adage "crunchy on the outside, chewy on the inside" still applies. Section 7.1.3 proposes
> a more efficient remediation: use a dedicated prefix for the SRv6 SIDs inside a domain,
> and apply filtering based on these SIDs not only at the border but also "in depth".
>
> Section 7.2 advocates convincingly for the use of encapsulation/decapsulation at domain boundaries,
> which would largely mitigate external attacks. That's very realistic.
>
> Section 7.3 point out that packet authentication based on well known keys is rather brittle,
> due to the difficulties of properly managing such keys. Indeed, we could see security issues
> if these keys leaked.
>
> Section 7.4 discusses the mitigation of control plane attacks. This may be something that we would
> want to develop in a separate document. Attackers who want to impair a network are likely to
> target some internal nodes to gain privileges -- typically, attacking the laptop of a
> network administrator to get a foothold, and from there using that administrator's
> access right to attack the network management functions. That attack chain can be used against
> SRv6, but it can also be used against networks that do not use SRv6. There are potential
> mitigations such as least privilege, isolation of function or early detection. Maybe that
> should be addressed in a different document.
>
> Section 8 discusses the effect of deploying SRv6 on existing hardware, such as firewalls that
> do not understand the SRv6 extensiens, or hardware that is not powerful enough to process the
> extension.
>
> Overall, I like this document a lot. My only little remark is that it does not discuss
> much potential pricacy issues. SRV6 header carry a significant amount of information,
> more information than the the basic IPv6 header. The leak of information through the
> IPv6 header information can be mitigated using techniques like privacy addresses or VPNs.
> Maybe the draft should discuss whether the SRV6 headers can be used to identify either the
> identity behind the addresses or the specific way in which a pair of endpoints communicates?

[TM] As mentioned above, privacy aspects have been added.

>
>