Dear Jean-Michel, Many thanks for a very thorough review. We have revised the document and we believe that the current version resolves almost all the issues: https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-security/12
Please see the replies below, marked [TM], along with a couple of text update suggestions that we would be happy to hear your opinion about. Thanks, Tal. On Tue, Feb 24, 2026 at 6:55 PM Jean-Michel Combes via Datatracker <[email protected]> wrote: > > 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> [TM] Right. Fixed. > > 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> [TM] Based on this comment and other comments from directorate reviewers we have significantly revised the text about "SR domain" and "trusted domain" in Section 4 (Threat Terminology). While the current document is not intended to redefine these terms, we believe that the current version is clearer about the meaning of these terms based on RFC 8402. > > <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> [TM] Rephrased. > > <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> [TM] Right. We have changed the reference, so that now we are using a reference to a different version of the document (published by the ITU-T) that is publicly available. As you pointed out, the referenced document is mostly focused on the management plane, but the scope of the referenced threat model is general and is not restricted to the management plane. > > * 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> [TM] Rephrased. > > * 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> [TM] You noted an example of an IP address that can be assigned in the case of a spoof/masquerade attack, and generally the current text mentions spoofing attacks without going into details or examples. > > * 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> [TM] Right, we have added a clarification to the end of Section 5 (Effect) that the categories are not mutually exclusive. > > <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> [TM] Right, see previous comment. > > <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> [TM] We believe that the current text is clear in this context. > > <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> [TM] We believe that the current text is clear in this context. > > <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> [TM] Right. Rephrased. > > <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> [TM] The table title was rephrased. > > 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> [TM] Rephrased. > > 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> [TM] Here is a proposal for updating this text: OLD: Traffic MUST be filtered at the domain boundaries. NEW: Traffic MUST be filtered at the domain boundaries. Filtering at SR ingress nodes is intended to mitigate modification and insertion attacks, while filtering at SR egress nodes is intended to mitigate outbound leaks. > > <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> [TM] Here is a proposal for updated text: OLD: A packet containing an SRH may not be destined to the SR domain. NEW: A packet containing an SRH may not be destined to the SR domain. This scenario is mitigated by encapsulating packets on the domain boundary, as discussed in Section 7.2. While inter‑SR‑domain scenarios are generally out of scope for this document’s threat model, the operational practices recommended here aim to preserve interoperability and avoid blanket behaviors that would break SR when adjacent networks follow different practices. > > 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]
