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 <[email protected]> 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. > > _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
