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.