Document: draft-ietf-spring-srv6-security Title: Segment Routing IPv6 Security Considerations Reviewer: Jean-Michel Combes Review result: Not Ready
Hi, I have been selected as the Operational Directorate (opsdir) reviewer for this Internet-Draft. The Operational Directorate reviews all operational and management-related Internet-Drafts to ensure alignment with operational best practices and that adequate operational considerations are covered. A complete set of _"Guidelines for Considering Operations and Management in IETF Specifications"_ can be found at https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/. While these comments are primarily for the Operations and Management Area Directors (Ops ADs), the authors should consider them alongside other feedback received. - Document: Segment Routing IPv6 Security Considerations (draft-ietf-spring-srv6-security-11) - Reviewer: Jean-Michel COMBES - Review Date: 2026-02-24 - Intended Status: Informational --- ## Summary The document is covering a large scope - I really appreciate the work done by the authors, but this document has major issues: Indeed, the main (and required) security mechanism mentioned inside in this document - SRv6 architecture in fact, is traffic filtering but, IMHO, the information on how to set-up it are not enough clear: precise information are needed so that such a mandatory mechanism could be correctly deployed and operated. Please, find my review below: Segment Routing IPv6 Security Considerations draft-ietf-spring-srv6-security-11 <snip> 4. Threat Terminology <snip> 1.on-path 2.on-path 3.mgmt. PCE as a Central 4.off-path 5.off-path external internal plane Controller internal external attacker attacker on-path (PCECC) attacker attacker | | | | | | | | v _____ v ____ _ | __ | | SR __ | _ __ / +---+ \___/ | \ | | domain / | \/ \_/ X-----|PCECC| v / v | \ | | +---+ X \ X v / v | / ----->X------>O--->X---------->O------->O-------------->O----> ^\ ^ /^\ /^ | \___/\_ /\_ | _/\__/ | \___/\______/ | | \__/ | | | | | | | SR SR SR SR ingress endpoint 1 endpoint 2 egress node node Figure 1: Threat Model Taxonomy <JMC> <Nits> Typo In Figure 1, s/3. mgmt. plane on-path/3. ctrl. plane on-path </Nits> </JMC> As defined in [RFC8402], SR operates within a "trusted domain". <JMC> <Major issue> No clear definition of “trusted domain” in RFC8402: what is the definition of “trusted domain”, for SR use case, from a technical/operational point of view? Is “trusted domain” only means “the traffic is filtered at the domain boundaries”, as mentioned in Section 7.1.1? </Major issue> </JMC> Therefore, in the current threat model the SR domain defines the boundary that distinguishes internal from external threats. <JMC> <Major issue> “Therefore,”: without definition of “trusted domain” (cf. above), I must admit it is hard for me to have such a conclusion. </Major issue> </JMC> <snip> 5. Effect One of the important aspects of threat analysis is assessing the potential effect or outcome of each threat. SRv6 allows for the forwarding of IPv6 packets via predetermined SR policies, which determine the paths and the processing of these packets. An attack on SRv6 may cause packets to traverse arbitrary paths and to be subject to arbitrary processing by SR endpoints within an SR domain. <JMC> <Minor issue> Only potential consequences for SR endpoints? </Minor issue> </JMC> <snip> The threat model in [ANSI-Sec] classifies threats according to their potential effect, defining six categories. For each of these categories we briefly discuss its applicability to SRv6 attacks. <JMC> <Major issue> (1) The reference [ANSI-Sec] is a draft document – at least the document pointed by the URL (2) The most recent version of the document is not available for free (cf. https://webstore.ansi.org/standards/atis/atis03002762008s2022) (3) The document seems focusing only on “management plane” – I didn’t read it (cf. point (2)), but is “management plane” definition for this document the same definition as the IETF definition (e.g., [RFC7276])? </Major issue> </JMC> * Unauthorized Access: an attack that results in unauthorized access might be achieved by having an attacker leverage SRv6 to circumvent security controls as a result of security devices that are unable to enforce security policies for SRv6. For example, this can occur if packets are directed through paths where packet filtering policies are not enforced, or if some security policies are not enforced in the presence of IPv6 Extension Headers. <JMC> <Nits> “an attack that results in unauthorized access might be achieved by having an attacker leverage SRv6 to circumvent security controls as a result of security devices that are unable to enforce security policies for SRv6.”: IMHO, hard to read. (Potential) Proposal: “an attack that might be achieved by leveraging SRv6 so that security controls are circumvented (e.g., security devices not SRv6 aware)” </Nits> </JMC> * Masquerade: various attacks that result in spoofing or masquerading are possible in IPv6 networks. However, these attacks are not specific to SRv6, and are therefore not within the scope of this document. <JMC> <Minor issue> As SRv6 specifies the “LOC:FUNCT:ARG” format for SID, is it not possible “to play” with it (i.e., specific impacts to SRv6)? Or the SR Source Node’s “Source Address” is not considered by the SRv6 process? </Minor issue> </JMC> * System Integrity: attacks on SRv6 can manipulate the path and the processing that the packet is subject to, thus compromising the integrity of the system. Furthermore, an attack that compromises the control plane and/or the management plane is also a means of affecting the system integrity. A specific SRv6-targeted attack may cause one or more of the following outcomes: - Avoiding a specific node or path: when an SRv6 policy is manipulated, specific nodes or paths may be bypassed, for example in order to avoid the billing service or circumvent access controls and security filters. <JMC> <Minor issue> “... or circumvent access controls and security filters”: looks like “Unauthorized Access” threat. What is the difference with this threat? </Minor issue> </JMC> <snip> * Communication Integrity: SRv6 attacks may cause packets to be forwarded through paths that the attacker controls, which may facilitate other attacks that compromise the integrity of user data. Integrity protection of user data, which is implemented in higher layers, avoids these aspects, and therefore communication integrity is not within the scope of this document. <JMC> <Minor issue> “SRv6 attacks may cause packets to be forwarded through paths that the attacker controls”: looks like “System Integrity – Preferring” threat. What is the difference with this threat? </Minor issue> </JMC> <snip> 6.2.1.1. Overview An on-path internal attacker can modify a packet while it is in transit in a way that directly affects the packet's segment list. <JMC> <Minor issue> “An on-path internal attacker can modify ...” I would remove “internal” from the sentence because: (1) at this point (cf. (2), a malicious actor could modify a packet outside of the SR domain if the packet is outside of the SR domain (2) Section 6.2.1.2 provides the reason, based on filtering rules, to restrict the attack to only an internal attacker </Minor issue> </JMC> <snip> 6.2.2.1. Overview An on-path internal attacker can passively listen to packets and specifically listen to the SRv6-related information that is conveyed in the IPv6 header and the SRH. This approach can be used for reconnaissance, i.e., for collecting segment lists. <JMC> <Minor issue> “An on-path internal attacker can passively ...” Same comment as previously: I would remove “internal” in this sentence. </Minor issue> </JMC> <snip> 6.2.3. Packet Insertion <JMC> <Minor issue> “replaying” is mentioned in the following sections. (Potential) Proposal: s/”Packet Insertion”/”Packet Insertion/Packet replaying” </Minor issue> </JMC> <snip> 6.5. Attacks - Summary The following table summarizes the attacks that were described in the previous subsections, and the corresponding effect of each of the attacks. Details about the effect are described in Section 5. +=============+==================+===================================+ | Attack | Details | Effect | +=============+==================+===================================+ |Modification |Modification of: |* Unauthorized access | | |* SID list |* Avoiding a specific node or path | | |* IPv6 DA |* Preferring a specific path | | |Add/remove/modify:|* Causing header modifications | | |* SRH |* Causing packets to be discarded | | |* SRH TLV |* Resource exhaustion | | | |* Forwarding loops | +-------------+------------------+-----------------------------------+ |Passive |Passively listen |* Reconnaissance | |listening |to SRv6-related | | | |information | | +-------------+------------------+-----------------------------------+ |Packet |Maliciously inject|* Resource exhaustion | |insertion |packets with a |* Security tooling confusion | | |segment list | | +-------------+------------------+-----------------------------------+ |Control plane|* Routing protocol| | |attacks | attacks | | | |* OAM attacks | | | |* Central control | | | | plane attacks |* Unauthorized access | | | |* Avoiding a specific node or path | | | |* Preferring a specific path | +-------------+------------------+* Causing header modifications | |Management |* Centralized |* Causing packets to be discarded | |plane attacks| management |* Resource exhaustion | | | attacks |* Forwarding loops | | |* Unauthorized | | | | access to the | | | | management | | | | system | | +-------------+------------------+-----------------------------------+ Figure 2: Attack Summary <JMC> <Nits> s/Figure 2: Attack Summary/Figure 2: Attacks Summary </Nits> </JMC> 7. Mitigation Methods This section presents methods that can be used to mitigate the threats and issues that were presented in previous sections. This section does not introduce new security solutions or protocols. <JMC> <Minor issue> “This section presents methods that can be used” As “traffic MUST be filtered” is a requirement, IMHO, s/”can be used”/”must/can be used” </Minor issue> </JMC> 7.1. Trusted Domains and Filtering 7.1.1. Overview As specified in [RFC8402]: By default, SR operates within a trusted domain. Traffic MUST be filtered at the domain boundaries. The use of best practices to reduce the risk of tampering within the trusted domain is important. Such practices are discussed in [RFC4381] and are applicable to both SR-MPLS and SRv6. Following the direction of [RFC8402], the current document assumes that SRv6 is a trusted domain and that the traffic is filtered at the domain boundaries. Traffic MUST be filtered at the domain boundaries. Thus, most of the attacks described in this document are limited to within the domain (i.e., internal attackers). <JMC> <Major issue> “Traffic MUST be filtered at the domain boundaries.”: Ingress filtering? (as assumed in RFC 8402 and RFC 8754) Egress filtering? (as assumed in Section 6.2.1.2 and Section 6.2.2.2) Both? (based on the previous 2 points) </Major issue> </JMC> <snip> 7.1.2. SRH Filtering Filtering can be performed based on the presence of an SRH. More generally, [RFC9288] provides recommendations on the filtering of IPv6 packets containing IPv6 extension headers at transit routers. However, filtering based on the presence of an SRH is not necessarily useful for two reasons: 1. The SRH is optional for SID processing as described in [RFC8754] section 3.1 and 4.1. 2. A packet containing an SRH may not be destined to the SR domain, it may be simply transiting the domain. <JMC> <Major issue> “2. A packet containing an SRH may not be destined to the SR domain” IMHO, not consistent with Section 6.2.1.2, Section 6.2.2.2 and Section 6.2.3.2: where does this packet come from? </Major issue> </JMC> For these reasons SRH filtering is not necessarily a useful method of mitigation. <JMC> <Major issue> IMHO, not consistent with RFC 8402, Section 8.2: “Therefore, by default, the explicit routing information MUST NOT be leaked through the boundaries of the administered domain.” IMHO, not consistent also with Section 6.2.1.2, Section 6.2.2.2 and Section 6.2.3.2 </Major issue> </JMC> Hope that helps. Thanks in advance for your reply. Best regards, JMC. _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
