Internet DRAFT - draft-bdmgct-spring-srv6-security

draft-bdmgct-spring-srv6-security







Source Packet Routing in Networking                          N. Buraglio
Internet-Draft                                   Energy Sciences Network
Intended status: Standards Track                              T. Mizrahi
Expires: 4 September 2024                                         Huawei
                                                                 T. Tong
                                                            China Unicom
                                                         L. M. Contreras
                                                              Telefonica
                                                            3 March 2024


                      SRv6 Security Considerations
                  draft-bdmgct-spring-srv6-security-01

Abstract

   SRv6 is a traffic engineering, encapsulation and steering mechanism
   utilizing IPv6 addresses to identify segments in a pre-defined
   policy.  This document discusses security considerations in SRv6
   networks, including the potential threats and the possible mitigation
   methods.  The document does not define any new security protocols or
   extensions to existing protocols.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://buraglio.github.io/draft-bdmgct-spring-srv6-security/draft-
   bdmgct-spring-srv6-security.html.  Status information for this
   document may be found at https://datatracker.ietf.org/doc/draft-
   bdmgct-spring-srv6-security/.

   Discussion of this document takes place on the Source Packet Routing
   in Networking Working Group mailing list (mailto:spring@ietf.org),
   which is archived at https://mailarchive.ietf.org/arch/browse/
   spring/.  Subscribe at https://www.ietf.org/mailman/listinfo/spring/.

   Source for this draft and an issue tracker can be found at
   https://github.com/buraglio/draft-bdmgct-spring-srv6-security.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.






Buraglio, et al.        Expires 4 September 2024                [Page 1]

Internet-Draft        SRv6 Security Considerations            March 2024


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 4 September 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Threat Model  . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Security Components . . . . . . . . . . . . . . . . . . .   5
       3.1.1.  Confidentiality . . . . . . . . . . . . . . . . . . .   5
       3.1.2.  Integrity . . . . . . . . . . . . . . . . . . . . . .   5
       3.1.3.  Availability  . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Threat Abstractions . . . . . . . . . . . . . . . . . . .   5
     3.3.  Threat Taxonomy . . . . . . . . . . . . . . . . . . . . .   6
   4.  Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  SR Modification Attack  . . . . . . . . . . . . . . . . .   8
       4.1.1.  Overview  . . . . . . . . . . . . . . . . . . . . . .   8
       4.1.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . .   8
       4.1.3.  Impact  . . . . . . . . . . . . . . . . . . . . . . .   8
     4.2.  Reconnaissance  . . . . . . . . . . . . . . . . . . . . .  10
       4.2.1.  Overview  . . . . . . . . . . . . . . . . . . . . . .  10
       4.2.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . .  10
       4.2.3.  Impact  . . . . . . . . . . . . . . . . . . . . . . .  10



Buraglio, et al.        Expires 4 September 2024                [Page 2]

Internet-Draft        SRv6 Security Considerations            March 2024


     4.3.  Packet Insertion  . . . . . . . . . . . . . . . . . . . .  10
       4.3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . .  10
       4.3.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . .  10
       4.3.3.  Impact  . . . . . . . . . . . . . . . . . . . . . . .  11
     4.4.  Control and Management Plane Attacks  . . . . . . . . . .  11
       4.4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . .  11
       4.4.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . .  11
       4.4.3.  Impact  . . . . . . . . . . . . . . . . . . . . . . .  11
     4.5.  Other Attacks . . . . . . . . . . . . . . . . . . . . . .  12
   5.  Mitigation Methods  . . . . . . . . . . . . . . . . . . . . .  12
     5.1.  Filtering . . . . . . . . . . . . . . . . . . . . . . . .  12
       5.1.1.  SRH Filtering . . . . . . . . . . . . . . . . . . . .  12
       5.1.2.  Address Range Filtering . . . . . . . . . . . . . . .  12
     5.2.  Encapsulation of Packets  . . . . . . . . . . . . . . . .  13
   6.  Implications on Existing Equipment  . . . . . . . . . . . . .  13
     6.1.  Limitations in Filtering Capabilities . . . . . . . . . .  13
     6.2.  Middlebox Filtering Issues  . . . . . . . . . . . . . . .  13
     6.3.  Emerging technology growing pains . . . . . . . . . . . .  14
   7.  Gap Analysis  . . . . . . . . . . . . . . . . . . . . . . . .  14
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   10. Topics for Further Consideration  . . . . . . . . . . . . . .  14
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  16
     11.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

   Segment Routing (SR) [RFC8402] utilizing an IPv6 data plane is a
   source routing model that leverages an IPv6 underlay and an IPv6
   extension header called the Segment Routing Header (SRH) to signal
   and control the forwarding and path of packets by imposing an ordered
   list of path details that are processed at each hop along the
   signaled path.  Because SRv6 is fundamentally bound to the IPv6
   protocol, and because of the reliance of a new header there are
   security considerations which must be noted or addressed in order to
   operate an SRv6 network in a reliable and secure manner.
   Specifically, some of the main properties of SRv6 that affect the
   security considerations are:

   *  SRv6 makes use of the SRH which is a new type of Routing Extension
      Header.  Some of the security considerations of the SRH are
      discussed in [RFC5095] and [RFC8754].






Buraglio, et al.        Expires 4 September 2024                [Page 3]

Internet-Draft        SRv6 Security Considerations            March 2024


   *  SRv6 consists of using the SRH on the IPv6 dataplane, and
      therefore known security considerations of IPv6 [RFC9099] are
      applicable to SRv6 as well.

   *  While SRv6 uses what appear to be typical IPv6 addresses, the
      address space is processed differently by segment endpoints.  A
      typical IPv6 unicast address is comprised of a network prefix,
      host identifier, and a subnet mask.  A typical SRv6 segment
      identifier (SID) is broken into a locator, a function identifier,
      and optionally, function arguments.  The locator must be routable,
      which enables both SRv6 capable and incapable devices to
      participate in forwarding, either as normal IPv6 unicast or SRv6.
      The capability to operate in environments that may have gaps in
      SRv6 support allows the bridging of islands of SRv6 devices with
      standard IPv6 unicast routing.

   This document describes various threats to SRv6 networks and also
   presents existing approaches to avoid or mitigate the threats.

2.  Conventions and Definitions

2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.2.  Terminology

   *  SID: Segment Identifier [RFC8402]

   *  SRH: Segment Routing Header [RFC8754]

   *  SRv6: Segment Routing over IPv6 [RFC8402]

3.  Threat Model

   This section introduces the threat model that is used in this
   document.  The model is based on terminology from the Internet threat
   model [RFC3552], as well as some concepts from [RFC9055] and
   [RFC7384].  Details regarding inter-domain segment routing (SR) are
   out of scope for this document.







Buraglio, et al.        Expires 4 September 2024                [Page 4]

Internet-Draft        SRv6 Security Considerations            March 2024


3.1.  Security Components

   The main components of information security are confidentiality,
   integrity and availability, often referred to by the acronym CIA.  A
   short description of each of these components is presented below in
   the context of SRv6 security.

3.1.1.  Confidentiality

   The purpose of confidentiality is to protect the user data from being
   exposed to unauthorized users, i.e., preventing attackers from
   eavesdropping to user data.  The confidentiality of user data is
   outside the scope of this document.  However, confidentiality aspects
   of SRv6-related information are within the scope; collecting
   information about SR endpoint addresses, SR policies, and network
   topologies, is a specific form of reconnaissance, which is further
   discussed in Section 4.2.

3.1.2.  Integrity

   Preventing information from being modified is a key property of
   information security.  Other aspects of integrity include
   authentication, which is the ability to verify the source of
   information, and authorization, which enforces different permission
   policies to different users or sources.  In the context of SRv6,
   compromising the integrity may result in packets being routed in
   different paths than they were intended to be routed through, which
   may have various implications, as further discussed in Section 4.

3.1.3.  Availability

   Protecting the availability of a system means keeping the system
   running continuously without disruptions.  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).

3.2.  Threat Abstractions

   A security attack is 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.




Buraglio, et al.        Expires 4 September 2024                [Page 5]

Internet-Draft        SRv6 Security Considerations            March 2024


   *  Packet replaying: in a replay attack the attacker records one or
      more packets and transmits them at a later point in time.

   *  Packet insertion: an attacker generates and injects a packet to
      the network.  The generated packet may be maliciously crafted to
      include false information, including for example false addresses
      and SRv6-related 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.

   *  Packet modification: the attacker modifies packets during transit.

3.3.  Threat Taxonomy

   The threat terminology used in this document is based on [RFC3552].
   Threats are classified according to two main criteria: internal vs.
   external attackers, and on-path vs. off-path attackers, as discussed
   in [RFC9055].

   Internal vs. External:  An internal attacker in the context of SRv6
      is an attacker who is located within an SR domain.  Specifically,
      an internal attacker either has access to a node in the SR domain,
      or is located on an internal path between two nodes in the SR
      domain.  In this context, the latter means that the attacker can
      be reached from a node in the SR domain without traversing an SR
      egress node, and can reach a node in the SR domain without
      traversing an SR ingress node.  External attackers, on the other
      hand, are not within the SR domain.

   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.

   The following figure depicts the attacker types according to the
   taxonomy above.  As illustrated in the figure, on-path attackers are
   located along the path of the traffic that is under attack, and
   therefore can listen, insert, delete, modify or replay packets in
   transit.  Off-path attackers can insert packets, and in some cases
   can passively listen to some of the traffic, such as multicast
   transmissions.







Buraglio, et al.        Expires 4 September 2024                [Page 6]

Internet-Draft        SRv6 Security Considerations            March 2024


        on-path         on-path        off-path      off-path
        external        internal       internal      external
        attacker        attacker       attacker      attacker
          |                   |        |__            |
          |     SR      __    | __   _/|  \           |
          |     domain /  \_/ |   \_/  v   \__        v
          |            \      |        X      \       X
          v            /      v                \
    ----->X---------->O------>X------->O------->O---->
                      ^\               ^       /^
                      | \___/\_    /\_ | _/\__/ |
                      |        \__/    |        |
                      |                |        |
                     SR               SR        SR
                     ingress        endpoint    egress
                     node                       node

                      Figure 1: Threat Model Taxonomy

   In the current threat model the SR domain defines the boundary that
   distinguishes internal from external threats.  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.

   In the context of the current document it is assumed that SRv6 is
   deployed within a limited domain [RFC8799] with filtering at the
   domain boundaries, forming a trusted domain with respect to SRv6.
   Thus, external attackers are outside of the trusted domain.
   Specifically, an attack on one domain that is invoked from within a
   different domain is considered an external attack in the context of
   the current document.

   Following the spirit of [RFC8402], the current document mandates a
   filtering mechanism that eliminates the threats from external
   attackers.  This approach limits the scope of the attacks described
   in this document to within the domain (i.e., internal attackers).

   It should be noted that in some threat models the distinction between
   internal and external attackers depends on whether an attacker has
   access to a cryptographically secured (encrypted or authenticated)
   domain.  Specifically, in some of these models there is a distinction
   between an attacker who becomes internal by having physical access,
   for example by plugging into an active port of a network device, and



Buraglio, et al.        Expires 4 September 2024                [Page 7]

Internet-Draft        SRv6 Security Considerations            March 2024


   an attacker who has full access to a legitimate network node,
   including for example encryption keys if the network is encrypted.
   The current model does not distinguish between these two types of
   attackers and there is no assumption about whether the SR domain is
   cryptographically secured or not.

4.  Attacks

4.1.  SR Modification Attack

4.1.1.  Overview

   An attacker can modify a packet while it is in transit in a way that
   directly affects the packet's SR policy.  The modification can affect
   the destination address of the IPv6 header and/or the SRH.  In this
   context SRH modification may refer to inserting an SRH, removing an
   SRH, or modifying some of the fields of an existing SRH.

   Modification of an existing SRH can be further classified into
   several possible attacks.  Specifically, the attack can include
   adding one or more SIDs to the segment list, removing one or more
   SIDs or replacing some of the SIDs with differnet SIDs.  Another
   possible type of modification is by adding, removing or modifying TLV
   fields in the SRH.

   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
   [I-D.ietf-spring-srv6-srh-compression].  SRH compression allows to
   encode multiple compressed SIDs within a single 128-bit SID, and thus
   modifying the DA can affect one or more hops in the SR policy.

4.1.2.  Scope

   An SR modification attack can be performed by on-path attackers.  As
   discussed in Section 3, it assumed that filtering is deployed at the
   domain boundaries, thus limiting the ability of implementing SR
   modification attacks to on-path internal attackers.

4.1.3.  Impact

   The SR modification attack allows an attacker to change the SR policy
   that the packet is steered through and thus to manipulate the path
   and the processing that the packet is subject to.





Buraglio, et al.        Expires 4 September 2024                [Page 8]

Internet-Draft        SRv6 Security Considerations            March 2024


   Specifically, the SR modification attack can impact the network and
   the forwarding behavior of packets in one or more of the following
   ways:

   Avoiding a specific node or path:  An attacker can manipulate the DA
      and/or SRH in order to avoid a specific node or path.  This
      approach can be used, for example, for bypassing the billing
      service or avoiding access controls and security filters.

   Preferring a specific path:  The packet can be manipulated to avert
      packets to a specific path.  This attack can result in allowing
      various unauthorized services such as traffic acceleration.
      Alternatively, an attacker can avert traffic to be forwarded
      through a specific node that the attacker has access to, thus
      facilitating more complex on-path attacks such as passive
      listening, recon and various man-in-the-middle attacks.  It is
      noted that the SR modification attack is performed by an on-path
      attacker who has access to packets in transit, and thus can
      implement these attacks directly.  However, SR modification is
      relatively easy to implement and requires low processing resources
      by an attacker, while it facilitates more complex on-path attacks
      by averting the traffic to another node that the attacker has
      access to and has more processing resources.

   Forwarding through a path that causes the packet to be discarded:  SR
      modification may casue a packet to be forwarded to a point in the
      network where it can no longer be forwarded, causing the packet to
      be discarded.

   Manipulating the SRv6 network programming:  An attacker can trigger a
      specific endpoint behavior by modifying the destination address
      and/or SIDs in the segment list.  This attack can be invoked in
      order to manipulate the path or in order to exhaust the resources
      of the SR endpoint.

   Availability:  An attacker can add SIDs to the segment list in order
      to increase the number hops that each packet is forwarded through
      and thus increase the load on the network.  For example, a set of
      SIDs can be inserted in a way that creates a forwarding loop
      ([RFC8402], [RFC5095]) and thus loads the nodes along the loop.
      Network programming can be used in some cases to manipulate
      segment endpoints to perform unnecessary functions that consume
      processing resources.  Path inflation, malicious looping and
      unnecessary instructions have a common outcome, resource
      exhaustion, which may in severe cases cause Denial of Service
      (DoS).





Buraglio, et al.        Expires 4 September 2024                [Page 9]

Internet-Draft        SRv6 Security Considerations            March 2024


4.2.  Reconnaissance

4.2.1.  Overview

   An on-path attacker can passively listen to packets and specifically
   to the SRv6-related information that is conveyed in the IPv6 header
   and the SRH.  This approach can be used for collecting information
   about SIDs and policies, and thus to facilitate mapping the structure
   of the network and its potential vulnerabilities.

4.2.2.  Scope

   A recon attack is limited to on-path internal attackers.

   It is assumed that the SRv6 domain is filtered in a way that prevents
   any leaks of explicit SRv6 routing information through the boundaries
   of the administrative domain.  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.

4.2.3.  Impact

   While the information collected in a recon 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.

4.3.  Packet Insertion

4.3.1.  Overview

   In this attack packets are inserted (injected) into the network with
   a segment list that defines a specific SR policy.  The attack can be
   applied either by using synthetic packets or by replaying previously
   recorded packets.

4.3.2.  Scope

   Packet insertion can be performed by internal attackers, either on-
   path or off-path.  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.

   SRv6 domains are assumed to be filtered in a way that mitigates
   insertion attacks from external attackers.






Buraglio, et al.        Expires 4 September 2024               [Page 10]

Internet-Draft        SRv6 Security Considerations            March 2024


4.3.3.  Impact

   The main impact of this attack is resource exhaustion which
   compromises the availability of the network, as described in
   Section 4.1.3.

4.4.  Control and Management Plane Attacks

4.4.1.  Overview

   Depending on the control plane protocols used in a network, it is
   possible to use the control plane as a way of compromising the
   network.  For example, an attacker can advertise SIDs in order to
   manipulate the SR policies used in the network.  A wide range of
   attacks can be implemented, including injecting control plane
   messages, selectively removing legitimate messages, replaying them or
   passively listening to them.

   A compromised management plane can also facilitate a wide range of
   attacks, including manipulating the SR policies or compromising the
   network availability.

4.4.2.  Scope

   Control plane attacks can be performed by internal attackers.
   Injection can be performed by off-path attackers, while removal,
   replaying and listening require on-path access.  The scope of
   management attacks depends on the specific management protocol and
   architecture.

   It is assumed that SRv6 domain boundary filtering is used for
   mitigating potential control plane and management plane attacks from
   external attackers.  Segment routing does not define any specific
   security mechanisms in existing control plane or management plane
   protocols.  However, existing control plane and management plane
   protocols use authentication and security mechanisms to validate the
   authenticity of information.

4.4.3.  Impact

   A compromised control plane or management plane can impact the
   network in various possible ways.  SR policies can be manipulated by
   the attacker to avoid specific paths or to prefer specific paths, as
   described in Section 4.1.3.  Alternatively, the attacker can
   compromise the availability, either by defining SR policies that load
   the network resources, as described in Section 4.1.3, or by
   blackholing some or all of the SR policies.  A passive attacker can
   use the control plane or management plane messages as a means for



Buraglio, et al.        Expires 4 September 2024               [Page 11]

Internet-Draft        SRv6 Security Considerations            March 2024


   recon, in a similar manner to Section 4.1.3.

4.5.  Other Attacks

   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.

   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],
   however, this is out of scope for this document.

5.  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.

5.1.  Filtering

5.1.1.  SRH Filtering

   SRv6 packets rely on the routing header in order to steer traffic
   that adheres to a defined SRv6 traffic policy.  Thus, SRH filtering
   can be enforced at the ingress and egress nodes of the SR domain, so
   that packets with an SRH cannot be forwarded into the SR domain or
   out of the SR domain.  Specifically, such filtering is performed by
   detecting Next Header 43 (Routing Header) with Routing Type 4 (SRH).

   Because of the methodologies used in SID compression
   [I-D.ietf-spring-srv6-srh-compression], SRH compression does not
   necessarily use an SRH.  In practice this means that when compressed
   segment lists are used without an SRH, filtering based on the Next
   Header is not relevant, and thus filtering can only be applied baed
   on the address range, as described below.

5.1.2.  Address Range Filtering

   The IPv6 destination address can be filtered at the SR ingress node
   in order to mitigate external attacks.  An ingress packet with a
   destination address that defines an active segment with an SR
   endpoint in the SR domain is filtered.

   In order to apply such a filtering mechanism the SR domain needs to
   have an allocated address range that can be detected and enforced by
   the SR ingress, for example by using LUA addresses.



Buraglio, et al.        Expires 4 September 2024               [Page 12]

Internet-Draft        SRv6 Security Considerations            March 2024


   Note that the use of GUA addressing in data plane programming could
   result in an fail open scenario when appropriate border filtering is
   not implemented or supported.

5.2.  Encapsulation of Packets

   Packets steered in an SR domain are often encapsulated in an IPv6
   encapsulation.  This mechanism allows for encapsulation of both IPv4
   and IPv6 packets.  Encapsulation of packets at the SR ingress node
   and decapsulation at the SR egress node mitigates the ability of
   external attackers to impact SR steering within the domain.

6.  Implications on Existing Equipment

6.1.  Limitations in Filtering Capabilities

   [RFC9288] provides recommendations on the filtering of IPv6 packets
   containing IPv6 extension headers at transit routers.  SRv6 relies on
   the routing header (RH4).  Because the technology is reasonably new,
   many platforms, routing and otherwise, do not posses the capability
   to filter and in some cases even provide logging for IPv6 next-header
   43 Routing type 4.

6.2.  Middlebox Filtering Issues

   When an SRv6 packet is forwarded in the SRv6 domain, its destination
   address changes constantly, the real destination address is hidden.
   Security devices on SRv6 network may not learn the real destination
   address and fail to take access control on some SRv6 traffic.

   The security devices on SRv6 networks need to take care of SRv6
   packets.  However, the SRv6 packets usually use loopback address of
   the PE device a as source address.  As a result, the address
   information of SR packets may be asymmetric, resulting in improper
   filter traffic problems, which affects the effectiveness of security
   devices.  For example, along the forwarding path in SRv6 network, the
   SR-aware firewall will check the association relationships of the
   bidirectional VPN traffic packets.  And it is able to retrieve the
   final destination of SRv6 packet from the last entry in the . When
   the <source, destination> tuple of the packet from PE1 to PE2 is
   <PE1-IP-ADDR, PE2-VPN-SID>, and the other direction is <PE2-IP-ADDR,
   PE1-VPN-SID>, the source address and destination address of the
   forward and backward VPN traffic are regarded as different flow.
   Eventually, the legal traffic may be blocked by the firewall.

   SRv6 is commonly used as a tunneling technology in operator networks.
   To provide VPN service in an SRv6 network, the ingress PE
   encapsulates the payload with an outer IPv6 header with the SRH



Buraglio, et al.        Expires 4 September 2024               [Page 13]

Internet-Draft        SRv6 Security Considerations            March 2024


   carrying the SR Policy segment List along with the VPN service SID.
   The user traffic towards SRv6 provider backbone will be encapsulated
   in SRv6 tunnel.  When constructing an SRv6 packet, the destination
   address field of the SRv6 packet changes constantly and the source
   address field of the SRv6 packet is usually assigned using an address
   on the originating device, which may be a host or a network element
   depending on configuration.  This may affect the security equipment
   and middle boxes in the traffic path.  Because of the existence of
   the SRH, and the additional headers, older security appliances,
   monitoring systems, and middle boxes cold react in different ways if
   they are unaware of the additional header and tunneling mechanisms
   leveraged by SRv6.  This lack of awareness may be due to software
   limits, or in some cases as has been seen in other emerging
   technologies, may be due to limits in ASICs or NPUs that could
   silently drop or otherwise impede SRv6 packets.  [RFC6169]

6.3.  Emerging technology growing pains

7.  Gap Analysis

   This section analyzes the security related gaps with respect to the
   threats and issues that were discussed in the previous sections.

8.  Security Considerations

   The security considerations of SRv6 are presented throughout this
   document.

9.  IANA Considerations

   This document has no IANA actions.

10.  Topics for Further Consideration

   This section lists topics that will be discussed further before
   deciding whether they need to be included in this document, as well
   as some placeholders for items that need further work.

   *  The following references may be used in the future: RFC9256
      [RFC8986]

   *  SRH compression

   *  Spoofing

   *  Path enumeration





Buraglio, et al.        Expires 4 September 2024               [Page 14]

Internet-Draft        SRv6 Security Considerations            March 2024


   *  Infrastructure and topology exposure: this seems like a non-issue
      from a WAN perspective.  Needs more thought - could be problematic
      in a host to host scenario involving a WAN and/or a data center
      fabric.

   *  Terms that may be used in a future version: Locator Block, FRR,
      uSID

   *  L4 checksum: [RFC8200] specifies that when the Routing header is
      present the L4 checksum is computed by the originating node based
      on the IPv6 address of the last element of the Routing header.
      When compressed segment lists
      [I-D.ietf-spring-srv6-srh-compression] are used, the last element
      of the Routing header may be different than the Destination
      Address as received by the final destination.  Furthermore,
      compressed segment lists can be used in the Destination Address
      without the presence of a Routing header, and in this case the
      IPv6 Destination address can be modified along the path.  As a
      result, some existing middleboxes which verify the L4 checksum
      might miscalculate the checksum.  This issue is currently under
      discusison in the SPRING WG.

   *  Segment Routing Header figure: the SRv6 Segment Routing Header
      (SRH) is defined in [RFC8754].

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Next Header   |  Hdr Ext Len  | Routing Type  | Segments Left |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Last Entry   |     Flags     |              Tag              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |            Segment List[0] (128 bits IPv6 address)            |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                                                               |
                                     ...
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |            Segment List[n] (128 bits IPv6 address)            |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Buraglio, et al.        Expires 4 September 2024               [Page 15]

Internet-Draft        SRv6 Security Considerations            March 2024


11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

11.2.  Informative References

   [I-D.ietf-spring-srv6-srh-compression]
              Cheng, W., Filsfils, C., Li, Z., Decraene, B., and F.
              Clad, "Compressed SRv6 Segment List Encoding", Work in
              Progress, Internet-Draft, draft-ietf-spring-srv6-srh-
              compression-13, 29 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              srv6-srh-compression-13>.

   [IANAIPv6SPAR]
              "IANA IPv6 Special-Purpose Address Registry", n.d.,
              <https://www.iana.org/assignments/iana-ipv6-special-
              registry/iana-ipv6-special-registry.xhtml>.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,
              <https://www.rfc-editor.org/rfc/rfc3552>.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
              December 2005, <https://www.rfc-editor.org/rfc/rfc4301>.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
              DOI 10.17487/RFC4302, December 2005,
              <https://www.rfc-editor.org/rfc/rfc4302>.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, DOI 10.17487/RFC4303, December 2005,
              <https://www.rfc-editor.org/rfc/rfc4303>.







Buraglio, et al.        Expires 4 September 2024               [Page 16]

Internet-Draft        SRv6 Security Considerations            March 2024


   [RFC4942]  Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
              Co-existence Security Considerations", RFC 4942,
              DOI 10.17487/RFC4942, September 2007,
              <https://www.rfc-editor.org/rfc/rfc4942>.

   [RFC5095]  Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
              of Type 0 Routing Headers in IPv6", RFC 5095,
              DOI 10.17487/RFC5095, December 2007,
              <https://www.rfc-editor.org/rfc/rfc5095>.

   [RFC6169]  Krishnan, S., Thaler, D., and J. Hoagland, "Security
              Concerns with IP Tunneling", RFC 6169,
              DOI 10.17487/RFC6169, April 2011,
              <https://www.rfc-editor.org/rfc/rfc6169>.

   [RFC7384]  Mizrahi, T., "Security Requirements of Time Protocols in
              Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
              October 2014, <https://www.rfc-editor.org/rfc/rfc7384>.

   [RFC7855]  Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
              Litkowski, S., Horneffer, M., and R. Shakir, "Source
              Packet Routing in Networking (SPRING) Problem Statement
              and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
              2016, <https://www.rfc-editor.org/rfc/rfc7855>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/rfc/rfc8402>.

   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
              <https://www.rfc-editor.org/rfc/rfc8754>.

   [RFC8799]  Carpenter, B. and B. Liu, "Limited Domains and Internet
              Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
              <https://www.rfc-editor.org/rfc/rfc8799>.

   [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
              D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
              (SRv6) Network Programming", RFC 8986,
              DOI 10.17487/RFC8986, February 2021,
              <https://www.rfc-editor.org/rfc/rfc8986>.







Buraglio, et al.        Expires 4 September 2024               [Page 17]

Internet-Draft        SRv6 Security Considerations            March 2024


   [RFC9055]  Grossman, E., Ed., Mizrahi, T., and A. Hacker,
              "Deterministic Networking (DetNet) Security
              Considerations", RFC 9055, DOI 10.17487/RFC9055, June
              2021, <https://www.rfc-editor.org/rfc/rfc9055>.

   [RFC9099]  Vyncke, É., Chittimaneni, K., Kaeo, M., and E. Rey,
              "Operational Security Considerations for IPv6 Networks",
              RFC 9099, DOI 10.17487/RFC9099, August 2021,
              <https://www.rfc-editor.org/rfc/rfc9099>.

   [RFC9256]  Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
              A., and P. Mattes, "Segment Routing Policy Architecture",
              RFC 9256, DOI 10.17487/RFC9256, July 2022,
              <https://www.rfc-editor.org/rfc/rfc9256>.

   [RFC9288]  Gont, F. and W. Liu, "Recommendations on the Filtering of
              IPv6 Packets Containing IPv6 Extension Headers at Transit
              Routers", RFC 9288, DOI 10.17487/RFC9288, August 2022,
              <https://www.rfc-editor.org/rfc/rfc9288>.

Acknowledgments

   The authors would like to acknowledge the contributions from Andrew
   Alston, Dale Carder, Bruno Decraene, Joel Halpern, Alvaro Retana, and
   Eric Vyncke.

Authors' Addresses

   Nick Buraglio
   Energy Sciences Network
   Email: buraglio@forwardingplane.net


   Tal Mizrahi
   Huawei
   Email: tal.mizrahi.phd@gmail.com


   Tian Tong
   China Unicom
   Email: tongt5@chinaunicom.cn


   Luis M. Contreras
   Telefonica
   Email: luismiguel.contrerasmurillo@telefonica.com





Buraglio, et al.        Expires 4 September 2024               [Page 18]