[spring] Fwd: Fwd: comments on srv6-security-14

[Joel Halpern <[e-mail]>]

I was asked to forward the below to the list.

Yours,

Joel

---------- Forwarded message ---------
From: *Daniel Migault* <[e-mail]>
Date: Thu, Jun 4, 2026 at 3:57 PM
Subject: comments on srv6-security-14
To: <[e-mail]>


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