I was asked to forward the below to the list.
Yours,
Joel
---------- Forwarded message ---------
From: *Daniel Migault* <[email protected]>
Date: Thu, Jun 4, 2026 at 3:57 PM
Subject: comments on srv6-security-14
To: <[email protected]>
Hi,
Please find below my comments on the security architecture draft. I
apologize for the
length — there are quite a few, but overall the draft is on the right track.
My main comment is that the threat model could be strengthened — the
document might benefit from exploring what happens when the "trusted
domain" assumption does not fully hold, perhaps drawing on established
models like Dolev-Yao, which would help readers understand the residual
risks and the importance of mechanisms like HMAC and MACsec in providing
concrete security guarantees.
Yours,
Daniel
some additional details:
4. Threat Terminology
[...]
On-path vs. Off-path: On-path attackers are located in a position
that allows interception, modification or dropping of in-flight
packets, as well as insertion (generation) of packets. Off-path
attackers can only attack by insertion of packets.
<mglt>
Perhaps the term 'injection' may be more suitable than 'insertion'.
</mglt>
[...]
1.on-path 2.on-path 3.cont. 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
This document uses the term "SR domain" as defined in [RFC8402]: "the
set of nodes participating in the source-based routing model...". By
default, [RFC8402] assumes operation "within a trusted domain" with
traffic filtered at the domain boundaries, as further discussed in
Section 7.1. In this document, unless stated otherwise, the boundary
that distinguishes internal from external attackers is the boundary
of the SR domain, and the term trusted domain denotes an SR domain
for which the boundary-filtering assumption of [RFC8402] is in force.
Note that the trusted domain is a logical/operational construct, not
a physical boundary. Thus, hosts and servers on the same physical
network are not part of the trusted domain unless explicitly brought
under its controls.
<mglt>
I comprehend that 8799 defines the "trusted boundaries" as setting
limits on the interpretation of the SRV6 header within a particular
scope, while also noting that packets escaping this scope could cause
damage. Furthermore, this section indicates that the IPv6 header can be
interpreted by both SRV6 and non-SRV6 aware devices. I believe this
aspect is absent from the analysis.
Another consideration is that 8402 presumes all nodes within the SR are
legitimate; at least, this is my interpretation of the text below.
Therefore, if we rely solely on 8402, we can essentially conclude that
there is no internal attacker. Depending on such assumptions
significantly simplifies the analysis. I believe these assumptions may
be overly strong for this document and somewhat outdated, especially as
we transition to zero trust architectures.
I anticipate that the document will advance further and examine the
potential risks if the concept of a trusted domain is flawed, along with
the safeguards that should be implemented.
For instance, the threat model that we typically use for security
analysis is the Dolev-Yao model, which states that "the attacker is
assumed to have complete control of the network between the
communicating parties" (see 8446 appendix E). I think this should serve
as the foundation for that analysis.
"""
From a network-protection standpoint, there is an assumed trust model
such that any node adding an SRH to the packet is assumed to be
allowed to do so. Therefore, by default, the explicit routing
information MUST NOT be leaked through the boundaries of the
administered domain. Segment Routing extensions that have been
defined in various protocols, leverage the security mechanisms of
these protocols such as encryption, authentication, filtering, etc.
"""
</mglt>
[...]
5. Effect
[...]
The threat model in [ITU-Sec] classifies threats according to their
potential effect, defining six categories. For each of these
categories we briefly discuss its applicability to SRv6 attacks.
* Unauthorized Access: an attacker may leverage SRv6 to circumvent
security controls when security devices fail to enforce SRv6
policies. 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.
* Masquerade: various attacks that result in spoofing or
masquerading are possible in IPv6 networks (e.g., [RFC9099]).
However, these attacks are not specific to SRv6, and are therefore
not within the scope of this document.
<mglt>
I believe that any area related to SRV6 falls within the scope of this
document. However, it remains ambiguous how masquerading differs from
system integrity. It appears to me that masquerading pertains to data
plane packets that are either redirected or sent along a specific path,
whereas system integrity assumes that the attacker has control over the
control plane, allowing them to define any path they desire. I am
curious if this is the key distinction between the two.
</mglt>
* 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.
Buraglio, et al. Expires 15 October 2026 [Page 7]
Internet-Draft Segment Routing IPv6 Security Considerat April 2026
- Preferring a specific path: packets can be manipulated so that
they are diverted to a specific path. This can result in
allowing various unauthorized services such as traffic
acceleration. Alternatively, an attacker can divert traffic to
be forwarded through a specific node that the attacker has
access to, which facilitates more complex on-path attacks such
as passive listening, reconnaissance, and various man-in-the-
middle attacks.
- Causing header modifications: SRv6 network programming
[RFC8986] determines the SR endpoint behavior, including
potential header modifications. Thus, one of the potential
outcomes of an attack is unwanted header modifications.
* 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.
<mglt>
It is accurate to state that higher layers such as ESP or TLS can
safeguard user data. Nevertheless, within the context of SRV6, only the
components necessary for routing the packet should be taken into
account. I believe that AH is inapplicable since the IPv6 header is
modified at each node. In this scenario, communication integrity is
solely ensured by MACsec. While MACsec secures the communication, it
does not protect against a malicious node that is under the control of
an attacker.
</mglt>
* Confidentiality: as in communication integrity, packets forwarded
through unintended paths may traverse nodes controlled by the
attacker. Since eavesdropping of user data can be avoided by
using encryption in higher layers, it is not within the scope of
this document. However, eavesdropping of a network that uses SRv6
is a specific form of reconnaissance. This reconnaissance allows
the attacker to collect information about SR endpoint addresses,
SR policies, and network topologies.
<mglt>
I concur that, in this instance, I hold the view that SRV6 does not
offer any mechanisms to maintain the confidentiality of SRV6-related
information, as such information is accessible at each node. Conversely,
it appears to me that MACsec is capable of ensuring confidentiality at
the link level.
</mglt>
* Denial of Service: the availability aspects of SRv6 include the
ability of attackers to leverage SRv6 as a means for compromising
the performance of a network or for causing Denial of Service
(DoS), including:
- Resource exhaustion: compromising the availability of the
system can be achieved by sending SRv6-enabled packets to/
through victim nodes in a way that results in a negative
performance impact of the victim systems (e.g., [RFC9098]).
For example, network programming can be used in some cases to
manipulate segment endpoints to perform unnecessary functions
that consume processing resources. Resource exhaustion may in
severe cases cause Denial of Service (DoS).
<mglt>
I lack some background information on this topic, but I am curious
whether SRV6 is exclusively intended for routing packets along a
specified path, or if it can also be utilized to direct packets to
execute particular functions, similar to NSH. I intend to view SRV6 as a
mechanism for guiding packets through designated paths.
Manipulating paths can result in congestion at links and nodes when
packets are rerouted onto alternative paths. This issue may be
exacerbated by the formation of loops; however, from a packet's
perspective, I believe it can also introduce delays, which in the case
of time-sensitive packets, may lead to complications—specifically, the
invalidation of packets.
</mglt>
[...]
6. Attacks
<mglt>
I am currently reviewing the section titled 'Effect' concerning the
objectives accomplished by an attacker. These overarching goals may be
attained through the implementation of various Tactics - refer to TTP.
It appears that this section aims to assess the attack surface available
to an attacker through traffic listening or injection. Perhaps a term
like 'attack techniques' would be more suitable.
It is essential to specify when these techniques can be executed. If we
assume that SRV6 can only be safeguarded by MACsec, then passive
listening, spoofing, or packet manipulation can only be executed by an
attacker who has compromised a node. In the absence of MACsec
deployment, any on-path attacker can carry out such techniques. I
believe this point should be explicitly articulated.
</mglt>
6.1. Attack Abstractions
Packet manipulation and processing attacks can be implemented by
performing a set of one or more basic operations. These basic
operations (abstractions) are as follows:
* Passive listening: an attacker who reads packets off the network
can collect information about SR endpoint addresses, SR policies
and the network topology. This information can then be used to
deploy other types of attacks.
* Packet replaying: in a replay attack the attacker records one or
more packets and transmits them at a later point in time. This
could lead to using more resources or security devices being
unable to track connections correctly.
<mglt>
I would likely regard replaying attacks as a distinct category of packet
injection attacks. Perhaps spoofing is more suitable than injection.
</mglt>
* Packet insertion: an attacker generates and injects a packet to
the network. The generated packet may be maliciously crafted to
include false information; including false addresses, SRv6-related
information, or other intentionally incorrect information.
* Packet deletion: by intercepting and removing packets from the
network, an attacker prevents these packets from reaching their
destination. Selective removal of packets may, in some cases,
cause more severe damage than random packet loss.
<mglt>
Perhaps it is more appropriate to refer to packet drop rates instead of
packet deletion. This is merely a suggestion.
</mglt>
* Packet modification: the attacker modifies packets during transit.
<mglt>
Modification appears to be synonymous with spoofing. There may be a
difference between a packet constructed from a specific packet and a
packet that is entirely spoofed by an off-path attacker. If this
distinction is necessary, it might be prudent to clarify the reasons
behind it.
</mglt>
Buraglio, et al. Expires 15 October 2026 [Page 9]
Internet-Draft Segment Routing IPv6 Security Considerat April 2026
This section describes attacks that are based on packet manipulation
and processing, as well as attacks performed by other means. While
it is possible for packet manipulation and processing attacks against
all the fields of the IPv6 header and its extension headers, this
document limits itself to the IPv6 header and the SRH.
<mglt>
My understanding is that the sequence of attacks has been organized in a
specific manner to guarantee that no types of attacks are overlooked. I
believe this order should be clearly defined. The manner in which I
think the list could have been constructed is as follows:
An on-path attacker may adopt a passive role by monitoring packets.
Alternatively, an on-path attacker may take an active role by dropping
packets or injecting them. The injected packets could be derived from
intercepted packets, allowing them to be replayed in their original form
without any alterations, or they could be slightly modified or entirely
fabricated.
</mglt>
6.2. Data Plane Attacks
6.2.1. Modification Attack
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.
A modification attack can be performed in one or more of the
following ways:
* SID list: the SRH can be manipulated by adding or removing SIDs,
or by modifying existing SIDs.
* IPv6 Destination Address (DA): when an SRH is present, modifying
the destination address (DA) of the IPv6 header affects the active
segment. However, DA modification can affect the SR policy even
in the absence of an SRH. One example is modifying a DA which is
used as a Binding SID [RFC8402]. Another example is modifying a
DA which represents a compressed segment list [RFC9800]. SRH
compression allows encoding multiple compressed SIDs within a
single 128-bit SID, and thus modifying the DA can affect one or
more hops in the SR policy.
* Add/remove SRH: an attacker can insert or remove an SRH.
* SRH TLV: adding, removing or modifying TLV fields in the SRH.
The SR modification attack is performed by an on-path attacker who
has access to packets in transit and can implement these attacks
directly.
<mglt>
It appears that there is a significant amount of repetition. I contend
that the statement, "The SR modification attack is executed by an
on-path" is adequate. Nevertheless, from the attacker's viewpoint, I
think it is important to address what drives the attacker to carry out
these modifications.
<mglt>
SR modification is relatively easy to implement and
requires low processing resources. However, it facilitates more
complex on-path attacks by redirecting traffic to another node that
the attacker has access to with more processing resources.
An on-path internal attacker can also modify, insert, or delete other
extension headers but these are outside the scope of this document.
<mglt>
In summary, an on-path attacker who alters the packet possesses full
control over the route taken by that packet.
</mglt>
Buraglio, et al. Expires 15 October 2026 [Page 10]
Internet-Draft Segment Routing IPv6 Security Considerat April 2026
6.2.1.2. Scope
An SR modification attack can be performed by on-path attackers. If
filtering is deployed at the domain boundaries as described in
Section 7.1, the ability to implement SR modification attacks is
limited to on-path internal attackers.
<mglt>
My understanding is that SR modifications can solely be performed by an
on-path attacker, meaning an attacker within the SR that is internal.
Additionally, I perceive that SRV6 headers are not utilized beyond the
SR. The purpose of such a subsection remains unclear to me.
</mglt>
6.2.1.3. Effect
SR modification attacks, including adding or removing an SRH,
modifying the SID list, and modifying the IPv6 DA, can have one or
more of the following outcomes, which are described in Section 5.
* Unauthorized access
* Avoiding a specific node or path
* Preferring a specific path
* Causing header modifications
* Causing packets to be discarded
* Resource exhaustion
* Forwarding loops
Maliciously adding unnecessary TLV fields can cause further resource
exhaustion.
<mglt>
I hold the view that there is excessive redundancy in section 5. This
section illustrates how Effect (the title of section 5) can be attained.
Consequently, section 5 turns into a result that does not require
reiteration. In my perspective, this section could be eliminated.
</mglt>
6.2.2. Passive Listening
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.
6.2.2.2. Scope
A reconnaissance attack is limited to on-path internal attackers.
Buraglio, et al. Expires 15 October 2026 [Page 11]
Internet-Draft Segment Routing IPv6 Security Considerat April 2026
<mglt>
I believe the text below primarily serves to prevent the attack from
being exported outside the SR. However, in this instance, I consider it
to be more of a misconfiguration rather than an actual attack.
Therefore, I think the paragraph below can be eliminated.
</mglt>
If filtering is deployed at the domain boundaries (Section 7.1), it
prevents any leaks of explicit SRv6 routing information through the
boundaries of the administrative domain. In this case, external
attackers can only collect SRv6-related data in a malfunctioning
network in which SRv6-related information is leaked through the
boundaries of an SR domain.
6.2.2.3. Effect
While the information collected in a reconnaissance attack does not
compromise the confidentiality of the user data, it allows an
attacker to gather information about the network which in turn can be
used to enable other attacks.
Passive eavesdropping can also impact end-user privacy. Observable
SRH fields (e.g., the Segment List and SRH TLVs) may enable
correlation of flows and tracking of users, endpoints, or services.
<mglt>
The preceding section lacks substantial information. It may be advisable
to eliminate that section.
</mglt>
6.2.3. Packet Insertion and Replaying
6.2.3.1. Overview
In a packet insertion attack packets are inserted (injected) into the
network with a segment list. The attack can be applied either by
using synthetic packets or by replaying previously recorded packets.
6.2.3.2. Scope
Packet insertion can be performed by either on-path or off-path
attackers. In the case of a replay attack, recording packets in-
flight requires on-path access and the recorded packets can later be
injected either from an on-path or an off-path location.
If filtering is deployed at the domain boundaries (Section 7.1),
insertion attacks can only be implemented by internal attackers.
6.2.3.3. Effect
<mglt>
I believe this section can be removed.
</mglt>
The main effect of this attack is resource exhaustion, which
compromises the availability of the network, as described in
Section 6.2.1.3.
6.2.4. Other Attacks
<mglt>
If they are not within the scope, these should not be referenced.
</mglt>
Various attacks which are not specific to SRv6 can be used to
compromise networks that deploy SRv6. For example, spoofing is not
specific to SRv6, but can be used in a network that uses SRv6. Such
attacks are outside the scope of this document.
Buraglio, et al. Expires 15 October 2026 [Page 12]
Internet-Draft Segment Routing IPv6 Security Considerat April 2026
Because SRv6 is completely reliant on IPv6 for addressing,
forwarding, and fundamental networking basics, it is potentially
subject to any existing or emerging IPv6 vulnerabilities [RFC9099].
This, however, is out of scope for this document.
[...]
7. Mitigation Methods
This section presents methods for mitigating the threats and issues
that were presented in previous sections. This section does not
introduce new security solutions or protocols.
7.1. Trusted Domains and Filtering
Buraglio, et al. Expires 15 October 2026 [Page 18]
Internet-Draft Segment Routing IPv6 Security Considerat April 2026
7.1.1. Overview
As specified in [RFC8402]:
By default, SR operates within a trusted domain. Traffic MUST be
filtered at the domain boundaries.
<mglt> Saying that we operate within trusted boundaries does not make
them trusted. The point of having security considerations is to make
these boundaries trusted.
</mglt>
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], and as discussed in Section 4,
the current document assumes that SRv6 is a trusted domain and that
the traffic is filtered at the domain boundaries.
<mglt> If we assume we are in a trusted domain, why do we care about
security ;-) </mglt>
Filtering at SR
ingress nodes is intended to mitigate modification and insertion
attacks,
<mglt>It is not entirely clear to me how filtering prevents injection,
or mitigation attacks. If the ingress nodes are he nodes at the SR
boundaries, the internal attacker is not concerned. If ingress policies
concerned every nodes within the SR these do not prevent these attacks.
Instead they will accept any packet that fits the policy. These node
will simply not accept packets that have not been modified by an
attacker. As I understand it, these policies doe not prevent such
attacks. The only make it necessary.
</mglt>
while filtering at SR egress nodes is intended to mitigate
outbound leaks. Thus, most of the attacks described in this document
are limited to within the domain (i.e., internal attackers).
It should be noted that relying on perfectly crafted filters on all
edges of the trusted domain poses a demonstrable risk of inbound or
outbound leaks if the filters are removed or adjusted erroneously.
It is also important to note that some filtering implementations have
limits on the size, complexity, or protocol support that can be
applied, which may prevent the filter adjustments or creation
required to properly secure the trusted domain for a new protocol
such as SRv6. Such an approach is commonly referred to as "fail-
open", which inherently contains more risk than fail-closed
methodologies.
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.
7.3. Hashed Message Authentication Code (HMAC)
<mglt>The HMAC is one way to address integrity protection. That should
be clearly mentioned in the section 5. </mglt>
[...]
--
Daniel Migault
Ericsson
--
Daniel Migault
Ericsson
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
