]> Energy Sciences Network

buraglio@forwardingplane.net

Huawei

tal.mizrahi.phd@gmail.com

China Unicom

tongt5@chinaunicom.cn

Telefonica

luismiguel.contrerasmurillo@telefonica.com

SI6 Networks

fgont@si6networks.com

Routing Source Packet Routing in Networking Internet-Draft Segment Routing over IPv6 (SRv6) is the instantiation of Segment Routing on the IPv6 data plane, using IPv6 addresses to identify segments. 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 The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Source Packet Routing in Networking Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Segment Routing (SR) utilizing an IPv6 data plane is a source routing model that leverages an IPv6 underlay. It uses an IPv6 extension header called the Segment Routing Header (SRH) . This header is used to signal and control the forwarding path of packets by imposing an ordered list of segments that are processed at each addressed node along the path. 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 primary properties of SRv6 that affect the security considerations are:

• Security considerations of the SRH are discussed in , and were based in part on security considerations of the deprecated routing header type 0 as discussed in . Unlike routing header 0, the SRH is processed only by the node whose SID is the destination address of the packet, and full implementation of the protection described in Section 5.1 of blocks the attacks documented in from outside the SR domain (Section 7.1 of ).
• Security considerations of IPv6 are applicable to SRv6 as well. Some of these considerations are discussed in Section 10 of and in .
• 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 and a host identifier. A typical SRv6 segment identifier (SID) is comprised of 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 segment endpoints. 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 forwarding.

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

Scope of this Document The following IETF RFCs were selected for security assessment as part of this effort:

• : Segment Routing Architecture
• : IPv6 Segment Routing Header (SRH)
• : Segment Routing over IPv6 (SRv6) Network Programming
• : YANG Data Model for Segment Routing
• : Segment Routing Policy Architecture
• : Integration of the Network Service Header (NSH) and Segment Routing for Service Function Chaining (SFC)
• : Segment Routing Replication for Multipoint Service Delivery
• : Compressed SRv6 Segment List Encoding

Inter-Domain Segment Routing scenarios are out of scope for this document as are existing and future protocol specific IPv6 vulnerabilities. Additionally, SRv6 is under active development and, as such, the above documents might not cover all protocols employed in an SRv6 deployment.

Terminology This document uses the term "SR domain" as defined in : "the set of nodes participating in the source-based routing model...". The document uses the following:

• HMAC TLV: Hashed Message Authentication Code Type Length Value
• SID: Segment Identifier
• SRH: Segment Routing Header
• SRv6: Segment Routing over IPv6
• MACsec: MAC Security

Threat Terminology This section introduces the threat taxonomy that is used in this document. This taxonomy is based on terminology from the Internet threat model , as well as some concepts from , , , and .

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 within the premises of the SR domain. 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.

Data plane vs. control plane vs. Management plane:

Attacks can be classified based on the plane they target: data, control, or management. The distinction between on-path and off-path attackers depends on the plane where the attack occurs. For instance, an attacker might be off-path from a data plane perspective but on-path from a control plane perspective.

depicts an example of an SR domain with five attacker types, labeled 1-5. As an example, attacker 2 is located along the path between the SR ingress node and SR endpoint 1, and is therefore an on-path attacker both in the data plane and in the control plane. Thus, attacker 2 can listen, insert, delete, modify, or replay data plane and/or control plane packets in transit. Off-path attackers, such as attackers 4 and 5, can insert packets and, in some cases, can passively listen to some traffic (such as multicast transmissions). In this example a Path Computation Element as a Central Controller (PCECC) is used as part of the control plane. Thus, attacker 3 is an internal on-path attacker in the control plane, as it is located along the path between the PCECC and SR endpoint 1.

Threat Model Taxonomy X------>O--->X---------->O------->O-------------->O----> ^\ ^ /^\ /^ | \___/\_ /\_ | _/\__/ | \___/\______/ | | \__/ | | | | | | | SR SR SR SR ingress endpoint 1 endpoint 2 egress node node ]]>

By default, assumes operation "within a trusted domain" with traffic filtered at the domain boundaries, as further discussed in . 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 is in force. A 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. In cases where cryptographic security mechanisms are deployed within or beneath the SRv6 data-plane (e.g., MACsec or the SRH HMAC ), an attacker is considered external to an SR domain if they lack access to the corresponding cryptographic keys. SRv6 deployments that exceed their trusted domain (per , Section 8) including cases where multiple SR instances exist under the same administrative entity, but are logically or operationally distinct, are out of the scope of this document. Where an attack originates from within a different trusted domain it is considered an external attack in the context of this document.

Effect One of the important aspects of threat analysis is assessing the potential effect or outcome of each threat. SRv6 allows for the forwarding of IPv6 packets via predetermined SR policies, which determine the paths and the processing of these packets. When the trust model of the SR domain is not enforced, an attack on SRv6 may cause packets to traverse arbitrary paths and to be subject to arbitrary processing by SR endpoints and transit routers within an SR domain. As with source routing and tunneling in other IP networks , this may allow an attacker to perform a number of attacks on the victim networks and hosts. The threat model in classifies threats according to their potential effect, defining six categories. The applicability of each these categories is discussed below:

• 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., ). However, these attacks are not specific to SRv6, and are therefore not within the scope of this document.
• 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 circumvent access controls and security filters.
  • Preferring a specific path: packets can be manipulated so that they are diverted to a specific path. 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 on-path attacks.
  • Causing header modifications: SRv6 network programming 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.
• Confidentiality: as in communication integrity, packets forwarded through unintended paths may traverse nodes controlled by an 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.
• Denial of Service (DoS): 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 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., ). 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 a DoS attack.
  • Forwarding loops: an attacker might achieve attack amplification by increasing the number of hops that each packet is forwarded through and thus increase the load on the network. For instance, a set of SIDs can be inserted in a way that creates a forwarding loop (, , ) and thus loads the nodes along the loop. As with source routing and tunneling in other IP networks , such loops are bounded by the Hop Limit, and from outside the SR domain they are blocked by the filtering of Section 7.1.
  • Causing packets to be discarded: an attacker may cause a packet to be forwarded to a point in the network where it can no longer be forwarded, causing the packet to be discarded.

Note that the categories in this section are effect‑based and intentionally not mutually exclusive; for example, "circumvent access controls and security filters" also falls under Unauthorized Access, but is listed here to emphasize the system integrity impact of path/policy manipulation. discusses specific implementations of these attacks, and possible mitigations are discussed in . The effects listed above are not unique to SRv6; they are shared by source routing and tunneling in other IP networks RFC5095. IP encapsulations such as IP-in-IP, GRE, MPLS-in-UDP, VXLAN, and Geneve operate under the same model of a trusted domain protected by filtering at its boundary RFC4023 . In addition, SRv6 provides an optional integrity check of the SRH (Section 7.3), a dedicated IPv6 prefix for SIDs that simplifies filtering , and locators that can be summarized (Section 7.1.3).

Attacks

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 be used to launch other types of attacks.
• Packet replaying: an 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.
• Packet insertion: an attacker generates and injects a packet in the network. The generated packet may be maliciously crafted to include false information; including fake 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.
• Packet modification: the attacker modifies packets during transit.

This section describes attacks that are based on packet manipulation and processing, as well as attacks performed by other means. While packet manipulation and processing attacks are possible against all the fields of the IPv6 header and its extension headers, this document limits itself to attacks on the IPv6 header and the SRH.

Data Plane Attacks

Modification Attack

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 . Another example is modifying a DA which represents a compressed segment list . 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. 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, with more processing resources, that the attacker has access to. An on-path internal attacker can also modify, insert, or delete other extension headers but these are outside the scope of this document.

Scope An SR modification attack can be performed by on-path attackers. If filtering is deployed at the domain boundaries as described in , the ability to implement SR modification attacks is limited to on-path internal attackers.

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 .

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

Passive Listening

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.

Scope A reconnaissance attack is generally limited to on-path internal attackers. If filtering is deployed at the domain boundaries (), it prevents any leaks of explicit SRv6 forwarding 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.

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 within the SR domain 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 endpoints or services, as the outer headers of other encapsulations can. As noted in Section 7.3 of , this disclosure is less relevant as an attacker has other means of learning topology, flows, and service usage, and with encapsulation at the domain boundary (Section 7.2) it does not extend beyond the SR domain.

Packet Insertion and Replaying

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.

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 (), insertion attacks can only be implemented by internal attackers.

Effect Packet insertion can have any of the effects of a modification attack (Section 6.2.1.3), since an inserted packet can carry any segment list; resource exhaustion is the most common. A packet from outside the SR domain that reached a service SID would amount to the service theft described in Section 7.2 of ; as for other IP-based overlays , this is prevented by the filtering at the SR domain boundary (Section 7.1 of this document, and Section 9.2 of ).

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

Control Plane Attacks

Overview The SRv6 control plane leverages existing control plane protocols, such as BGP, IS-IS, OSPF, and PCEP. Consequently, any security attacks that can potentially compromise these protocols are also applicable to SRv6 deployments utilizing them. Therefore, this document does not provide an exhaustive list of the potential control plane attacks. Instead, it highlights key categories of attacks, focusing on three primary areas: attacks targeting routing protocols, centralized control plane infrastructures, and OAM protocols. In this document, the term OAM refers specifically to Operations, Administration, and Maintenance, in alignment with the definition provided in . As such, it explicitly excludes management-related functions. Security considerations pertaining to the management plane are addressed in .

Routing Protocol Attacks

Overview Generic threats applicable to routing protocols are discussed in . Similar to data plane attacks, the abstractions outlined in are also applicable to control plane traffic. These include passive eavesdropping, message injection, replay, deletion, and modification. Passive listening enables an attacker to intercept routing protocol messages as they traverse the network. This form of attack does not alter the content of the messages but allows the adversary to analyze routing information, infer network topology, and gather intelligence on routing behavior. Active attacks involve the unauthorized injection or alteration of control plane messages. Such attacks can compromise routing integrity by introducing falsified information, modifying legitimate routing data, or triggering incorrect forwarding decisions. These disruptions may result in denial-of-service conditions or traffic misdirection. For example, an attacker may advertise falsified SIDs to manipulate SR policies. Another example in the context of SRv6 is the advertisement of an incorrect Maximum SID Depth (MSD) value, such as the SRv6 MSD types defined in Section 4 of and Section 4 of (with the general MSD framework described in ). If the advertised MSD is lower than the actual capability, path computation may fail to compute a viable path. Conversely, if the value is higher than supported, an attempt to instantiate a path that cannot be supported by the head-end (the node performing the SID imposition) may occur. An additional case could be the manipulation of backup paths, such as those computed by TI-LFA for the use cases of , where the attacker could alter the SIDs defining such backup path, then directing traffic over suboptimal or compromised paths, enabling eavesdropping, traffic analysis, or selective denial of service, compromising the service integrity and confidentiality if traffic is diverted to unauthorized nodes or paths. Finally, in situations of interworking with other domains, as for BGP Egress Peer Engineering (BGP-EPE) an attacker injecting malicious BGP-EPE policies may steer traffic through unauthorized peers or paths. This facilitates interception, traffic analysis, or denial of service. Attackers gaining access to the BGP-EPE controller can manipulate SRv6 route selection and segment lists, compromising network integrity and confidentiality.

Scope The location of an attacker in the network significantly affects the scope of potential attacks. Off-path attackers are generally limited to injecting malicious routing messages, while on-path attackers can perform a broader range of attacks, including active modification, or passive listening.

Effect Attacks targeting the routing protocol can have diverse impacts on network operation, including the aspects described in . These impacts may include incorrect SR policies or the degradation of network availability, potentially resulting in service disruption or denial of service.

OAM Attacks

Overview Since SRv6 operates over an IPv6 infrastructure, existing OAM protocols designed for IPv6 networks are applicable to SRv6 as well. Consequently, the security considerations associated with conventional IPv6 OAM protocols are also relevant to SRv6 environments. As noted in , successful attacks on OAM protocols can mislead operators by simulating non-existent failures or by concealing actual network issues. SRv6-specific OAM aspects are specified in . The O-flag in the SRH serves as a marking bit in user packets to trigger telemetry data collection and export at the segment endpoints. An attacker may exploit this mechanism by setting the O-flag in transit packets, thereby overloading the control plane and degrading system availability. Additionally, an on-path attacker may passively intercept OAM data exported to external analyzers, potentially gaining unauthorized insight into network topology and behavior.

Scope Off-path attackers may attempt to degrade system availability by injecting fabricated OAM messages or SRv6 packets with the O-flag set, thereby triggering unnecessary telemetry processing. They may also probe SRv6 nodes to infer information about network state and performance characteristics. On-path attackers possess enhanced capabilities due to their position within the traffic path. These include passive interception of OAM data, unauthorized modification of the O-flag in transit packets, and tampering with legitimate OAM messages to mislead network monitoring systems or conceal operational issues.

Effect Attacks targeting OAM protocols may impact network availability or facilitate unauthorized information gathering. Such attacks can disrupt normal operations or expose sensitive details about network topology, performance, or state.

Centralized Control Plane Attacks

Overview Centralized control plane architectures, such as those based on a PCE and PCE as a Central Controller (PCECC) , inherently introduce a focal point for attacks against the controller, such as DoS attacks, or attacks against one or many network element(s) under control of the PCE/PCECC in an SR domain, thereby increasing the risk of compromise to the overall network control infrastructure.

Scope As with other control plane attacks, an off-path attacker may attempt to inject forged control messages or impersonate a legitimate controller. On-path attackers, by virtue of their position within the communication path, possess additional capabilities such as passive interception of control traffic and in-transit modification of messages exchanged between the controller and Network Elements (NEs). For example, an attacker may manipulate SR policies instantiated via the central controller (using protocols like PCEP or BGP) at the head end, thereby altering both the paths of the SR policy and the traffic steered over it. Additionally, PCECC enables manipulation of SID allocation and distribution.

Effect A successful attack may result in any of the adverse effects described in , potentially impacting availability and operational correctness.

Management Plane Attacks

Overview Similar to the control plane, a compromised management plane can enable a broad range of attacks, including unauthorized manipulation of SR policies and disruption of network availability. The specific threats and their potential impact are influenced by the management protocols in use. As with centralized control systems, a centralized management infrastructure may introduce a single point of failure, rendering it susceptible to DoS attacks or making it a target for eavesdropping and message tampering. Unauthorized access in a network management system can enable attackers or unprivileged users to gain control over network devices and alter configurations. In SRv6-enabled environments, this can result in the manipulation of segment routing policies or cause DoS conditions by disrupting traffic or tampering with forwarding behavior. Management functionality is often defined using YANG data models, such as the Segment Routing base model and the SRv6 models in , , and . As with any YANG module, data nodes marked as writable, creatable, or deletable may be considered sensitive in certain operational environments. Unauthorized or unprotected write operations (e.g., via edit-config) targeting these nodes can adversely affect network operations. Some of the readable data nodes in a YANG module may also be considered sensitive or vulnerable in some network environments ().

Scope As with control plane attacks, an off-path attacker may attempt to inject forged management messages or impersonate a legitimate network management system. On-path attackers, due to their privileged position within the communication path, have additional capabilities such as passive interception of management traffic and unauthorized modification of messages in transit. An attacker with unauthorized access to a management system can cause significant damage, depending on the scope of the system and the strength of the access control mechanisms in place.

Effect A successful attack may result in any of the adverse effects described in , potentially impacting availability and operational correctness.

Attacks - Summary summarizes the attacks that were described in the previous subsections, and the corresponding effect of each of the attacks. Details about the effect are described in .

Summary of Attacks

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.

Trusted Domains and Filtering

Overview As specified in : Following the direction of , and as discussed in , the current document assumes that SRv6 is a trusted domain and that the traffic is filtered at the domain boundaries. Filtering at SR ingress nodes is intended to mitigate modification and insertion attacks, while filtering at SR egress nodes is intended to mitigate outbound leaks. Thus, most of the attacks described in this document are limited to within the domain (i.e., internal attackers). As in any IP network whose security relies on filtering at its boundary, relying on correctly configured filters on all edges of the trusted domain poses a risk of inbound or outbound leaks if the filters are removed or adjusted erroneously. When SIDs are allocated as described in and Section 7.1.3, the required filters are few and stable: they match a small number of summarized prefixes, which Section 7 of notes are easily supported by ACLs, using the same IPv6 address filters that protect the infrastructure of other IP networks . Where some filtering implementations nevertheless have limits on size or complexity (Section 8.2) that prevent the required filters from being applied, the domain is "fail-open", which inherently contains more risk than fail-closed methodologies. Practically speaking, this means that, as for other IP networks, enforcing a "Trusted Domain" depends on operational discipline, and that attacks that are expected to be unfeasible from outside the trusted domain may become feasible when any of the involved systems fails to enforce the filtering policy that is required to define the Trusted Domain.

SRH Filtering Filtering can be performed based on the presence of an SRH. More generally, provides recommendations on the filtering of IPv6 packets containing IPv6 extension headers at transit routers. However, filtering based on the presence of an SRH is not necessarily useful for two reasons:

1. The SRH is optional for SID processing as described in Section 3.1 and 4.1 of .
2. A packet containing an SRH may not be destined to the SR domain, as it may be simply transiting the domain. Such a packet is not destined to a SID of the domain, so it is forwarded as a plain IPv6 packet and its SRH is not inspected within the domain (Section 4.2 of ); a packet from outside the domain that is destined to a SID of the domain is dropped by the filtering described in Section 7.1.3. Packets from outside the SR domain are therefore not processed as SRv6 within it.

Therefore, filtering solely based on the presence of an SRH, at either SR ingress or SR egress, is not a useful method of mitigation. Where such transit traffic is carried across the SR domain using SRv6, it is encapsulated at the domain boundary as discussed in : the received packet, including any SRH, becomes the payload of an outer IPv6 header originated within the domain, and is tunneled through the transit SR domain without exercising SRv6 functions there. While inter-SR-domain scenarios are a violation of the trust model described above, the operational practices recommended here aim to preserve interoperability and avoid blanket behaviors that would break SR when adjacent networks follow different practices.

Address Range Filtering The IPv6 destination address can be filtered at the external interface of the SR ingress node of the SRv6 domain and at all nodes implementing SRv6 SIDs within the SR domain in order to mitigate external attacks. Section 5.1 of describes this in detail and a summary is presented here:

1. At ingress nodes, any packet entering the SR domain and destined to a SID within the SR domain is dropped.
2. At every SRv6 enabled node, any packet destined to a SID instantiated at the node from a source address outside the SR domain is dropped.

In order to apply such a filtering mechanism the SR domain needs to have an address range for SIDs, separate from the infrastructure and customer address ranges, and an infrastructure address range for source addresses, both of which can be detected and enforced. Together with encapsulation at the SR domain boundary (Section 7.2), which keeps SRH and SID information within the domain , this practice helps prevent the use of SRH and SID information to track individual users or reveal communication patterns outside the trusted domain. SIDs are best allocated from an address block dedicated to SIDs, for example:

• The prefix defined in
• A dedicated ULA block
• A dedicated GUA block

As stated in the security considerations section of , the usage of the prefix allocated by improves security by making it simpler to filter traffic at the edge of the SR Domains. It is important to note that allocates and makes a dedicated prefix available for SRv6 SIDs for use inside a trusted SRv6 domain. Use of other prefixes for this purpose will result in further security considerations such as potential SID pool route leakage or more complicated filtering requirements, increasing the likelihood of human or configuration error. Many operators reserve a /64 block for all loopback addresses and allocate /128 for each loopback interface. This simplifies the filtering of permitted source addresses. As in other IP networks, filtering at SRv6 enabled nodes complements address range filtering at ingress nodes, and it relies on the ingress source address validation that IP networks deploy against spoofing (BCP 38 and BCP 84 ). Failure to implement these filtering mechanisms could result in a "fail open" scenario, where some attacks by internal attackers described in this document may be launched by external attackers. Filtering on prefixes has been shown to be useful, specifically 's description of packet filtering. When SIDs are allocated from a dedicated block that can be summarized, the resulting filters are few and stable, and expands on the concept with control plane filtering.

Encapsulation of Packets In SRv6 deployments, an operator may steer traffic using IPv6-in-IPv6 encapsulation, imposing a new outer IPv6 header and SRH at the SR ingress node rather than processing SRH/SIDs on packets received directly from untrusted-facing interfaces. This is a specific case of the trusted-domain filtering discussed in Section 7.1: because the outer header and SRH are always originated by a trusted node, forwarding decisions within the domain never depend on header fields supplied by an untrusted source. Decapsulating the inner packet at the SR egress node, which then forwards it as specified by the behavior of the final segment endpoint , also prevents internal SR-domain information such as segment lists, SIDs, and/or TLVs from being exposed beyond the domain boundary. As discussed in Section 7.1.2, this practice also addresses the case of a packet carrying an SRH while only transiting rather than terminating within the domain. Encapsulation does not by itself protect against an attacker capable of injecting packets that satisfy the domain's boundary-filtering criteria (Section 7.1.3); it is complementary to, but not a substitute for, boundary filtering. Practices outlined in Section 5 of  describe this deployment model, including the address-range exclusivity assumptions its security properties depend on.

Hashed Message Authentication Code (HMAC) The integrity of the SRH can be protected by an HMAC TLV, as defined in . The HMAC is an optional TLV that secures the segment list, the SRH flags, the SRH Last Entry field and the IPv6 source address. A pre-shared key is used in the generation and verification of the HMAC. Using an HMAC in an SR domain can mitigate some of the SR Modification Attacks (). The following aspects of the HMAC should be considered:

• The HMAC TLV is optional .
• While it is presumed that unique keys will be employed by each participating node, manual configuration of pre-shared keys may lead to key reuse. In such scenarios, the same key might be reused by multiple nodes of an SRv6 domain as an incorrect shortcut to keep pre-shared key configuration manageable. This key should not be the same key for different trusted domains, including those existing on the same node.
• When the HMAC is used 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 an attacker who has full access to a legitimate network node, including for example encryption keys if the network is encrypted. The latter type of attacker is an internal attacker who can perform any of the attacks that were described in the previous section as relevant to internal attackers.
• For the lifetime of the pre-shared key validity, an internal attacker who does not have access to the pre-shared key can capture legitimate packets, and later replay the SRH and HMAC from these recorded packets. This allows the attacker to insert the previously recorded SRH and HMAC into a newly injected packet. An on-path internal attacker can also replace the SRH of an in-transit packet with a different SRH that was previously captured.
• In cases where an SRH carries policy semantics, care should be taken to understand the implications of malformed SRH, invalid TLVs, and authentication failures.
• An HMAC TLV as defined in Section 2.1.2 of covers Source Address, Last Entry, flags, and the segment list, excluding Segments Left. This could be used by an on-path attacker without the HMAC key to tamper with Segments Left alone, potentially redirecting which segment in an otherwise HMAC-valid list gets treated as active without invalidating the HMAC.

These considerations limit the extent to which HMAC TLV can be relied upon as a security mechanism that could readily mitigate threats associated with spoofing and tampering protection for the IPv6 SRH.

Control Plane Mitigation Methods Mitigation strategies for control plane attacks depend heavily on the specific protocols in use. Since these protocols are not exclusive to SRv6, this section does not attempt to provide an exhaustive list of mitigation techniques. Instead, it is focused on considerations particularly relevant to SRv6 deployments. Routing protocols can employ authentication and/or encryption to protect against modification, injection, and replay attacks, as outlined in . These mechanisms are essential for maintaining the integrity and authenticity of control plane communications. In centralized SRv6 control plane architectures RFC4655, such as those using the PCEP extensions of , it is recommended that communication between PCEs and PCCs be secured using authenticated and encrypted sessions. This is typically achieved using Transport Layer Security (TLS), following the guidance in and best practices in . When the O-flag is used for OAM functions, Section 2.1.1 of requires the processing node to rate-limit the number of packets punted to the OAM process, which mitigates denial-of-service attacks that exploit the O-flag. Furthermore, if the HMAC TLV is used, it provides integrity protection of the O-flag as described in . The control plane should be confined to a trusted administrative domain. As specified in and , SR Policy information advertised via BGP and BGP-LS should be restricted to authorized nodes, controllers, and applications within this domain. Similarly, the use of the O-flag is assumed to occur only within such a trusted environment, where the risk of abuse is minimized.

Management Plane Mitigation Methods Mitigating attacks on the management plane, much like in the control plane, depends on the specific protocols and interfaces employed. Management protocols such as NETCONF and RESTCONF are commonly used to configure and monitor SRv6-enabled devices. These protocols must be secured to prevent unauthorized access, configuration tampering, or information leakage. These YANG-based management protocols (1) have to use a secure transport layer (e.g., Secure Shell (SSH) [RFC4252], TLS , and QUIC [RFC9000]) and (2) have to use mutual authentication. The Network Configuration Access Control Model (NACM) provides the means to restrict access for particular NETCONF or RESTCONF users to a pre-configured subset of all available NETCONF or RESTCONF protocol operations and content. SRv6-specific YANG modules should be designed with the same security considerations applied to all YANG-based models. Writable nodes must be protected using access control mechanisms such as NACM and secured transport protocols like SSH or TLS to prevent unauthorized configuration changes. Readable nodes that expose sensitive operational data should be access-controlled and transmitted only over encrypted channels to mitigate the risk of information leakage.

Layer 2 Mitigation In some circumstances it may be possible to mitigate passive listening and packet insertion by leveraging to encrypt traffic at the media access control (MAC) layer by using encryption between two connected devices. This methodology prevents unauthorized access to traffic over a given point to point path by encrypting and authenticating data in transit at Layer 2, which prevents passive interception and mitigates packet-insertion DoS from unauthorized on-path nodes. Much like the encryption mechanisms noted for protocol communication and management access, this level of protection can provide integrity and authenticity to all higher layer communications over a given layer 2 path but comes with operational trade-offs and added complexity. Additionally, there are design scenarios where this is impractical or otherwise not possible.

Mitigations - Summary summarizes the possible mitigation methods for each of the attacks that were described in the previous section.

Summary of Mitigation Methods for each of the Attacks

Operational and Filtering Considerations

MiddleBox Filtering Issues When an SRv6 packet is forwarded in the SRv6 domain, its IPv6 destination address is modified in each segment and the final destination address is not available in the IPv6 header. As with other IP encapsulations RFC2003, security devices on SRv6 networks that are not SRv6-capable may not learn the real destination address and incorrectly perform access control on some SRv6 traffic. The security devices operating in SRv6 enabled networks need to understand and have the capability to process SRv6 packets. However, SRv6 packets are often encapsulated by an SR ingress device with an IPv6 encapsulation that has the loopback address of the SR ingress device as a source address. As a result, the address information of SR packets may be asymmetric, resulting in improper traffic filter 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. It is therefore able to retrieve the final destination of an SRv6 packet from Segment List[0] of the SRH ; when the SRH is absent or the segment list is compressed, the final destination is obtained by applying the segment behaviors as described in . When the <source, destination> tuple of the packet from PE1 (Provider Edge 1) 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 traffic are regarded as different flows. Thus, legitimate traffic may be blocked by the firewall. Consistent with Section 3.5.2.4 of , operators should avoid dropping packets that carry the SRH (Routing Type 4) within an SR domain and instead deploy filtering policies at transit routers that preserve SRv6 forwarding semantics. As with other encapsulations, forwarding SRv6 traffic through devices that are not SRv6-aware might in some cases lead to unpredictable behavior. Security appliances, monitoring systems, and middleboxes could react in different ways if they lack support for SRv6 mechanisms, such as the Segment Routing Header (SRH) . Additionally, implementation limitations in the processing of IPv6 packets with extension headers may result in SRv6 packets being dropped ,. Upper-layer checksum calculations rely on a pseudo-header that includes the IPv6 Destination Address. specifies that when the Routing header is present the upper-layer checksum is computed by the originating node based on the IPv6 address of the last element of the Routing header. When compressed segment lists 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 defined in , the Destination Address used in the upper-layer checksum calculation is the address as expected to be received by the ultimate destination. As a result, some existing middleboxes which verify the upper-layer checksum might miscalculate the checksum.

Limited Capability Hardware In some cases, Access Control List (ACL) capacity is a scarce and potentially shared hardware resource (e.g., TCAM/ACL tables). Depending on the scale of the network, filtering can consume a non-trivial portion of these resources. Since filtering resources can be shared with other features across a given hardware platform, filtering capabilities should be considered along with other hardware reliant functions such as VLAN scale, route table size, MAC address table size, etc. Filtering both at the control and data plane may or may not require shared resources. For example, some platforms may require allocating resources from route table size in order to accommodate larger numbers of access lists. Operators are advised to check the limitations of their platforms when deploying SRv6, and to keep the resources needed for filtering low by following the SID allocation and summarization practices described in Section 7.1.3.

Security Considerations The security considerations of SRv6 are presented throughout this document.

IANA Considerations This document has no IANA actions.

References Normative References Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. This document defines three YANG data models. The first is for Segment Routing (SR) configuration and operation, which is to be augmented by different Segment Routing data planes. The next is a YANG data model that defines a collection of generic types and groupings for SR. The third module defines the configuration and operational states for the Segment Routing MPLS data plane. Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy. This document describes the integration of the Network Service Header (NSH) and Segment Routing (SR), as well as encapsulation details, to efficiently support Service Function Chaining (SFC) while maintaining separation of the service and transport planes as originally intended by the SFC architecture. Combining these technologies allows SR to be used for steering packets between Service Function Forwarders (SFFs) along a given Service Function Path (SFP), whereas the NSH is responsible for maintaining the integrity of the service plane, the SFC instance context, and any associated metadata. This integration demonstrates that the NSH and SR can work cooperatively and provide a network operator with the flexibility to use whichever transport technology makes sense in specific areas of their network infrastructure while still maintaining an end-to-end service plane using the NSH. This document describes the Segment Routing Replication segment for multipoint service delivery. A Replication segment allows a packet to be replicated from a replication node to downstream nodes. Segment Routing over IPv6 (SRv6) is the instantiation of Segment Routing (SR) on the IPv6 data plane. This document specifies new flavors for the SRv6 endpoint behaviors defined in RFC 8986, which enable the compression of an SRv6 segment list. Such compression significantly reduces the size of the SRv6 encapsulation needed to steer packets over long segment lists. This document updates RFC 8754 by allowing a Segment List entry in the Segment Routing Header (SRH) to be either an IPv6 address, as specified in RFC 8754, or a REPLACE-CSID container in packed format, as specified in this document. Informative References All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Routing protocols are subject to attacks that can harm individual users or network operations as a whole. This document provides a description and a summary of generic threats that affect routing protocols in general. This work describes threats, including threat sources and capabilities, threat actions, and threat consequences, as well as a breakdown of routing functions that might be attacked separately. This memo provides information for the Internet community. Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains. This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community. This document is one of a series concerned with defining a roadmap of protocol specification work for the use of modern cryptographic mechanisms and algorithms for message authentication in routing protocols. In particular, it defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity. This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK] This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. A DetNet (deterministic network) provides specific performance guarantees to its data flows, such as extremely low data loss rates and bounded latency (including bounded latency variation, i.e., "jitter"). As a result, securing a DetNet requires that in addition to the best practice security measures taken for any mission-critical network, additional security measures may be needed to secure the intended operation of these novel service properties. This document addresses DetNet-specific security considerations from the perspectives of both the DetNet system-level designer and component designer. System considerations include a taxonomy of relevant threats and attacks, and associations of threats versus use cases and service properties. Component-level considerations include ingress filtering and packet arrival-time violation detection. This document also addresses security considerations specific to the IP and MPLS data plane technologies, thereby complementing the Security Considerations sections of those documents. As time and frequency distribution protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of security requirements for time protocols, focusing on the Precision Time Protocol (PTP) and the Network Time Protocol (NTP). This document also discusses the security impacts of time protocol practices, the performance implications of external security practices on time protocols, and the dependencies between other security services and time synchronization. Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset for fault detection and isolation, and for performance measurement. Over the years, various OAM tools have been defined for various layers in the protocol stack. This document summarizes some of the OAM tools defined in the IETF in the context of IP unicast, MPLS, MPLS Transport Profile (MPLS-TP), pseudowires, and Transparent Interconnection of Lots of Links (TRILL). This document focuses on tools for detecting and isolating failures in networks and for performance monitoring. Control and management aspects of OAM are outside the scope of this document. Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are also out of the scope of this document. The target audience of this document includes network equipment vendors, network operators, and standards development organizations. This document can be used as an index to some of the main OAM tools defined in the IETF. At the end of the document, a list of the OAM toolsets and a list of the OAM functions are presented as a summary. Poor selection of transient numerical identifiers in protocols such as the TCP/IP suite has historically led to a number of attacks on implementations, ranging from Denial of Service (DoS) or data injection to information leakages that can be exploited by pervasive monitoring. Due diligence in the specification of transient numeric identifiers is required even when cryptographic techniques are employed, since these techniques might not mitigate all the associated issues. This document formally updates RFC 3552, incorporating requirements for transient numeric identifiers, to prevent flaws in future protocols and implementations. This document presents real-world data regarding the extent to which packets with IPv6 Extension Headers (EHs) are dropped in the Internet (as originally measured in August 2014 and later in June 2015, with similar results) and where in the network such dropping occurs. The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 EHs so that the situation improves over time. This document also explains how the results were obtained, such that the corresponding measurements can be reproduced by other members of the community and repeated over time to observe changes in the handling of packets with IPv6 EHs. The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. This document describes PCEPS -- the usage of Transport Layer Security (TLS) to provide a secure transport for PCEP. The additional security mechanisms are provided by the transport protocol supporting PCEP; therefore, they do not affect the flexibility and extensibility of PCEP. This document updates RFC 5440 in regards to the PCEP initialization phase procedures. This document defines a way for an Open Shortest Path First (OSPF) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network. This document only refers to the Signaling MSD as defined in RFC 8491, but it defines an encoding that can support other MSD types. Here, the term "OSPF" means both OSPFv2 and OSPFv3. The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands. PCE was developed to derive paths for MPLS Label Switched Paths (LSPs), which are supplied to the head end of the LSP using the Path Computation Element Communication Protocol (PCEP). SDN has a broader applicability than signaled MPLS traffic-engineered (TE) networks, and the PCE may be used to determine paths in a range of use cases including static LSPs, segment routing, Service Function Chaining (SFC), and most forms of a routed or switched network. It is, therefore, reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller. This document briefly introduces the architecture for PCE as a central controller, examines the motivations and applicability for PCEP as a control protocol in this environment, and introduces the implications for the protocol. A PCE-based central controller can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. This document does not describe use cases in detail and does not define protocol extensions: that work is left for other documents. Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases. RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks. This document summarizes the operational implications of IPv6 extension headers specified in the IPv6 protocol specification (RFC 8200) and attempts to analyze reasons why packets with IPv6 extension headers are often dropped in the public Internet. The functionality provided by IPv6's Type 0 Routing Header can be exploited in order to achieve traffic amplification over a remote path for the purposes of generating denial-of-service traffic. This document updates the IPv6 specification to deprecate the use of IPv6 Type 0 Routing Headers, in light of this security concern. [STANDARDS-TRACK] This document describes how the existing IPv6 mechanisms for ping and traceroute can be used in a Segment Routing over IPv6 (SRv6) network. The document also specifies the OAM flag (O-flag) in the Segment Routing Header (SRH) for performing controllable and predictable flow sampling from segment endpoints. In addition, the document describes how a centralized monitoring system performs a path continuity check between any nodes within an SRv6 domain. This document analyzes the security implications of IPv6 Extension Headers and associated IPv6 options. Additionally, it discusses the operational and interoperability implications of discarding packets based on the IPv6 Extension Headers and IPv6 options they contain. Finally, it provides advice on the filtering of such IPv6 packets at transit routers for traffic not directed to them, for those cases where such filtering is deemed as necessary. Knowledge and experience on how to operate IPv4 networks securely is available, whether the operator is an Internet Service Provider (ISP) or an enterprise internal network. However, IPv6 presents some new security challenges. RFC 4942 describes security issues in the protocol, but network managers also need a more practical, operations-minded document to enumerate advantages and/or disadvantages of certain choices. This document analyzes the operational security issues associated with several types of networks and proposes technical and procedural mitigation techniques. This document is only applicable to managed networks, such as enterprise networks, service provider networks, or managed residential networks. This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. This document provides a threat analysis of the Locator/ID Separation Protocol (LISP). The Path Computation Element (PCE) is a core component of Software-Defined Networking (SDN) systems. A PCE as a Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the Label Switched Path (LSP) can be calculated/set up/initiated and the label-forwarding entries can also be downloaded through a centralized PCE server to each network device along the path while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and Path Computation Element Communication Protocol (PCEP) extensions for using the PCE as the central controller for provisioning labels along the path of the static LSP. Segment Routing over IPv6 (SRv6) uses IPv6 as the underlying data plane. Thus, Segment Identifiers (SIDs) used by SRv6 can resemble IPv6 addresses and behave like them while exhibiting slightly different behaviors in some situations. This document explores the characteristics of SRv6 SIDs and focuses on the relationship of SRv6 SIDs to the IPv6 Addressing Architecture. This document allocates and makes a dedicated prefix available for SRv6 SIDs. Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service based. SR allows for the enforcement of a flow through any topological path while maintaining per-flow state only at the ingress node of the SR domain. The Segment Routing architecture can be directly applied to the MPLS data plane with no change on the forwarding plane. It requires a minor extension to the existing link-state routing protocols. This document illustrates the application of Segment Routing to solve the BGP Egress Peer Engineering (BGP-EPE) requirement. The SR-based BGP-EPE solution allows a centralized (Software-Defined Networking, or SDN) controller to program any egress peer policy at ingress border routers or at hosts within the domain. At first glance, the acronym "OAM" seems to be well-known and well-understood. Looking at the acronym a bit more closely reveals a set of recurring problems that are revisited time and again. This document provides a definition of the acronym "OAM" (Operations, Administration, and Maintenance) for use in all future IETF documents that refer to OAM. There are other definitions and acronyms that will be discussed while exploring the definition of the constituent parts of the "OAM" term. This memo documents an Internet Best Current Practice. This document identifies and describes the requirements for a set of use cases related to Segment Routing network resiliency on Source Packet Routing in Networking (SPRING) networks. This document analyses the security of the BGP/MPLS IP virtual private network (VPN) architecture that is described in RFC 4364, for the benefit of service providers and VPN users. The analysis shows that BGP/MPLS IP VPN networks can be as secure as traditional layer-2 VPN services using Asynchronous Transfer Mode (ATM) or Frame Relay. This memo provides information for the Internet community. The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). A Segment Routing (SR) Policy is an ordered list of instructions called "segments" that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated. An SR Policy is made of one or more Candidate Paths. This document specifies the Path Computation Element Communication Protocol (PCEP) extension to signal Candidate Paths of an SR Policy. Additionally, this document updates RFC 8231 to allow delegation and setup of an SR Label Switched Path (LSP) without using the path computation request and reply messages. This document is applicable to both Segment Routing over MPLS (SR-MPLS) and Segment Routing over IPv6 (SRv6). This document describes a mechanism used to collect Segment Routing (SR) Policy information that is locally available in a node and advertise it into BGP - Link State (BGP-LS) updates. Such information can be used by external components for path computation, reoptimization, service placement, network visualization, etc. A number of security concerns with IP tunnels are documented in this memo. The intended audience of this document includes network administrators and future protocol developers. The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed and propose strategies for the mitigation of those issues. [STANDARDS-TRACK] Various applications of MPLS make use of label stacks with multiple entries. In some cases, it is possible to replace the top label of the stack with an IP-based encapsulation, thereby enabling the application to run over networks that do not have MPLS enabled in their core routers. This document specifies two IP-based encapsulations: MPLS-in-IP and MPLS-in-GRE (Generic Routing Encapsulation). Each of these is applicable in some circumstances. [STANDARDS-TRACK] This document specifies an IP-based encapsulation for MPLS, called MPLS-in-UDP for situations where UDP (User Datagram Protocol) encapsulation is preferred to direct use of MPLS, e.g., to enable UDP-based ECMP (Equal-Cost Multipath) or link aggregation. The MPLS- in-UDP encapsulation technology must only be deployed within a single network (with a single network operator) or networks of an adjacent set of cooperating network operators where traffic is managed to avoid congestion, rather than over the Internet where congestion control is required. Usage restrictions apply to MPLS-in-UDP usage for traffic that is not congestion controlled and to UDP zero checksum usage with IPv6. Network virtualization involves the cooperation of devices with a wide variety of capabilities such as software and hardware tunnel endpoints, transit fabrics, and centralized control clusters. As a result of their role in tying together different elements of the system, the requirements on tunnels are influenced by all of these components. Therefore, flexibility is the most important aspect of a tunneling protocol if it is to keep pace with the evolution of technology. This document describes Geneve, an encapsulation protocol designed to recognize and accommodate these changing capabilities and needs. The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called "segments". It can be implemented over the MPLS or the IPv6 data plane. This document describes the IS-IS extensions required to support SR over the IPv6 data plane. This document updates RFC 7370 by modifying an existing registry. The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called segments. It can be implemented over an MPLS or IPv6 data plane. This document describes the OSPFv3 extensions required to support SR over the IPv6 data plane. Futurewei Technologies Huawei Technologies Huawei Technologies Cisco Systems, Inc. LabN Consulting, L.L.C. This document defines a YANG data model that can be used to configure and manage OSPFv3 Segment Routing over the IPv6 Data Plane. Huawei Cisco Futurewei Technologies Huawei Huawei This document defines a YANG data model that can be used to configure and manage IS-IS Segment Routing over the IPv6 Data Plane. Cisco Systems Cisco Systems SoftBank Huawei Technologies Individual This document describes a YANG data model for Segment Routing IPv6 (SRv6) base. The model serves as a base framework for configuring and managing an SRv6 subsystem and expected to be augmented by other SRv6 models accordingly. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram. [STANDARDS-TRACK] This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document is concerned with security vulnerabilities in IPv6-in- IPv4 automatic tunnels. These vulnerabilities allow an attacker to take advantage of inconsistencies between the IPv4 routing state and the IPv6 routing state. The attack forms a routing loop that can be abused as a vehicle for traffic amplification to facilitate denial- of-service (DoS) attacks. The first aim of this document is to inform on this attack and its root causes. The second aim is to present some possible mitigation measures. It should be noted that at the time of this writing there are no known reports of malicious attacks exploiting these vulnerabilities. Nonetheless, these vulnerabilities can be activated by accidental misconfiguration. This document is not an Internet Standards Track specification; it is published for informational purposes. This document defines procedures and messages for SRv6-based BGP services, including Layer 3 Virtual Private Network (L3VPN), Ethernet VPN (EVPN), and Internet services. It builds on "BGP/MPLS IP Virtual Private Networks (VPNs)" (RFC 4364) and "BGP MPLS-Based Ethernet VPN" (RFC 7432). A Segment Routing (SR) Policy is an ordered list of segments (also referred to as "instructions") that define a source-routed policy. An SR Policy consists of one or more Candidate Paths (CPs), each comprising one or more segment lists. A headend can be provisioned with these CPs using various mechanisms such as Command-Line Interface (CLI), Network Configuration Protocol (NETCONF), Path Computation Element Communication Protocol (PCEP), or BGP. This document specifies how BGP can be used to distribute SR Policy CPs. It introduces a BGP SAFI for advertising a CP of an SR Policy and defines sub-TLVs for the Tunnel Encapsulation Attribute to signal information related to these CPs. Furthermore, this document updates RFC 9012 by extending the Color Extended Community to support additional steering modes over SR Policy. This document presents Topology Independent Loop-Free Alternate (TI-LFA) Fast Reroute (FRR), which is aimed at providing protection of node and Adjacency segments within the Segment Routing (SR) framework. This FRR behavior builds on proven IP FRR concepts being LFAs, Remote LFAs (RLFAs), and Directed Loop-Free Alternates (DLFAs). It extends these concepts to provide guaranteed coverage in any two-connected networks using a link-state IGP. An important aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the Point of Local Repair (PLR), reducing the operational need to control the tie-breaks among various FRR options. This document provides guidelines for authors and reviewers of specifications containing YANG data models, including IANA-maintained YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 8407; it also updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained YANG modules.

Acknowledgments The authors would like to acknowledge the valuable input and contributions from Zafar Ali, Andrew Alston, Dale Carder, Weiqiang Cheng, Bruno Decraene, Dhruv Dhody, Mike Dopheide, Darren Dukes, Linda Dunbar, Joel Halpern, Boris Hassanov, Tom Hill, Suresh Krishnan, Sam Öehlert, Alvaro Retana, Andrew Stone, Bala'zs Vargas, Eric Vyncke, and Russ White.