Subject: [spring] draft-ietf-spring-srv6-security-11 early Opsdir review
From: Jean-Michel Combes via Datatracker <[email-masked]>
To: <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Tue, 24 Feb 2026 08:55:43 -0800
List-Id: "Source Packet Routing in NetworkinG (SPRING)" <spring.ietf.org>

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.