Status of This Memo

This is an Internet Standards Track document.¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9524.¶

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

2. Replication Segment

In an SR domain, a Replication segment is a logical construct that connects a replication node to a set of downstream nodes. A Replication segment is a local segment instantiated at a Replication node. It can be either provisioned locally on a node or programmed by a control plane.¶

Replication segments can be stitched together to form a tree by either local provisioning on nodes or using a control plane. The procedures for doing this are out of scope of this document. One such control plane using a PCE with the SR P2MP policy is specified in [P2MP-POLICY]. However, if local provisioning is used to stitch Replication segments, then a chain of Replication segments SHOULD NOT form a loop. If a control plane is used to stitch Replication segments, the control plane specification MUST prevent loops or detect and mitigate loops in steady state.¶

A Replication segment is identified by the tuple <Replication-ID, Node-ID>, where:¶

Replication-ID:

An identifier for a Replication segment that is unique in context of the replication node.¶

Node-ID:

The address of the replication node for the Replication segment. Note that the root of a multipoint service is also a Replication node.¶

Replication-ID is a variable-length field. In the simplest case, it can be a 32-bit number, but it can be extended or modified as required based on the specific use of a Replication segment. This is out of scope for this document. The length of the Replication-ID is specified in the signaling mechanism used for the Replication segment. Examples of such signaling and extensions are described in [P2MP-POLICY]. When the PCE signals a Replication segment to its node, the <Replication-ID, Node-ID> tuple identifies the segment.¶

A Replication segment includes the following elements:¶

Replication-SID:

The Segment Identifier of a Replication segment. This is an SR-MPLS label or an SRv6 SID [RFC8402].¶

Downstream nodes:

Set of nodes in an SR domain to which a packet is replicated by the Replication segment.¶

Replication state:

See below.¶

The downstream nodes and Replication state (RS) of a Replication segment can change over time, depending on the network state and leaf nodes of a multipoint service that the segment is part of.¶

The Replication-SID identifies the Replication segment in the forwarding plane. At a replication node, the Replication-SID operates on the RS of the Replication segment.¶

RS is a list of Replication branches to the downstream nodes. In this document, each branch is abstracted to a <downstream node, downstream Replication-SID> tuple. <downstream node> represents the reachability from the replication node to the downstream node. In its simplest form, this MAY be specified as an interface or next-hop if the downstream node is adjacent to the replication node. The reachability may be specified in terms of a Flexible Algorithm path (including the default algorithm) [RFC9350] or specified by an SR-explicit path represented either by a SID list (of one or more SIDs) or by a Segment Routing Policy [RFC9256]. The downstream Replication-SID is the Replication-SID of the Replication segment at the downstream node.¶

A packet is steered into a Replication segment at a replication node in two ways:¶

• When the active segment [RFC8402] is a locally instantiated Replication-SID.¶
• By the root of a multipoint service based on local configuration that is outside the scope of this document.¶

In either case, the packet is replicated to each downstream node in the associated RS.¶

If a downstream node is an egress (leaf) of the multipoint service, no further replication is needed. The leaf node's Replication segment has an indicator for the leaf role, and it does not have any RS (i.e., the list of Replication branches is empty). The Replication-SID at a leaf node MAY be used to identify the multipoint service. Notice that the segment on the leaf node is still referred to as a "Replication segment" for the purpose of generalization.¶

A node can be a bud node (i.e., it is a replication node and a leaf node of a multipoint service [P2MP-POLICY]). The Replication segment of a bud node has a list of Replication branches as well as a leaf role indicator.¶

In principle, it is possible for different Replication segments to replicate packets to the same Replication segment on a downstream node. However, such usage is intentionally left out of scope of this document.¶

Replication state:
{
  Node-Role: {Head, Transit, Leaf, Bud};
  IPv6 Hop Limit Threshold; # default is zero
  # On Leaf, replication list is zero length
  Replication-List:
  {
    downstream node: <Node-Identifier>;
    downstream Replication-SID: R-SID;
    # Segment-List may be empty
    Segment-List: [SID-1, .... SID-N];
  }
}

S01. Replicate(RS, packet)
S02. {
S03.    For each Replication R in RS.Replication-List {
S04.       Make a copy of the packet
S05.       Set IPv6 DA = RS.R-SID
S06.       If RS.Segment-List is not empty {
S07.         # Head node may optimize below encapsulation and
S08.         # the encapsulation of packet in a single encapsulation
S09.         Execute H.Encaps or H.Encaps.Red with RS.Segment-List
             on packet copy #RFC 8986, Sections 5.1 and 5.2
S10.       }
S11.       Submit the packet to the egress IPv6 FIB lookup and
           transmission to the new destination
S12.   }
S13. }

S01.   Lookup FUNCT portion of S to get Replication state (RS)
S02.   If (IPv6 Hop Limit <= 1) {
S03.     Discard the packet
S04.     # ICMPv6 Time Exceeded is not permitted
           (see Section 2.2.3)
S05.   }
S06.   If RS is not found {
S07.     Discard the packet
S08.   }
S09.   If (IPv6 Hop Limit < RS.IPv6 Hop Limit Threshold) {
S10.     Discard the packet
S11.     # Rate-limited logging
S12.   }
S13.   Decrement IPv6 Hop Limit by 1
S14.   If (IPv6 NH == SRH and SRH TLVs present) {
S15.     Process SRH TLVs if allowed by local configuration
S16.   }
S17.   Call Replicate(RS, packet)
S18.   If (RS.Node-Role == Leaf OR RS.Node-Role == bud) {
S19.     If (IPv6 NH == SRH and Segments Left > 0) {
S20.       Derive packet processing context (PPC) from Segment List
S21.       If (Segments Left != 0) {
S22.         Discard the packet
S23.         # ICMPv6 Parameter Problem message with Code 0
S24.         # (Erroneous header field encountered)
S25.         # is not permitted (Section 2.2.3)
S26.       }
S27.     } Else {
S28.       Derive packet processing context (PPC)
           from FUNCT of Replicatio-SID
S29.     }
S30.     Process the next header
S31.   }

S01.   If (Upper-Layer header type == 4(IPv4) OR
           Upper-Layer header type == 41(IPv6) ) {
S02.     Remove the outer IPv6 header with all its extension headers
S03.     Process the packet in context of PPC
S04.   } Else If (Upper-Layer header type == 143(Ethernet) ) {
S05.     Remove the outer IPv6 header with all its extension headers
S06.     Process the Ethernet Frame in context of PPC
S07.   } Else If (Upper-Layer header type is allowed
                  by local configuration) {
S08.     Proceed to process the Upper-Layer header
S09.   } Else {
S10.     Discard the packet
S11.     # ICMPv6 Parameter Problem message with Code 4
S12.     # (SR Upper-Layer header Error)
S13.     # is not permitted (Section 2.2.3)
S14.   }

3. IANA Considerations

IANA has assigned the following codepoint for End.Replicate behavior in the "SRv6 Endpoint Behaviors" registry in the "Segment Routing" registry group.¶

4. Security Considerations

The SID behaviors defined in this document are deployed within an SR domain [RFC8402]. An SR domain needs protection from outside attackers (as described in [RFC8754]). The following is a brief reminder of the same:¶

• For SR-MPLS deployments:¶

  • Disable MPLS on external interfaces of each edge node or any other technique to filter labeled traffic ingress on these interfaces.¶

• For SRv6 deployments:¶

  • Allocate all the SIDs from an IPv6 prefix block S/s and configure each external interface of each edge node of the domain with an inbound Infrastructure Access Control List (IACL) that drops any incoming packet with a DA in S/s.¶

  • Additionally, an IACL may be applied to all nodes (k) provisioning SIDs as defined in this specification:¶

    • Assign all interface addresses from within IPv6 prefix A/a. At node k, all SIDs local to k are assigned from prefix Sk/sk. Configure each internal interface of each SR node k in the SR domain with an inbound IACL that drops any incoming packet with a DA in Sk/sk if the source address is not in A/a.¶
  • Deny traffic with spoofed source addresses by implementing recommendations in BCP 84 [RFC3704].¶
  • Additionally, the block S/s from which SIDs are allocated may be an address that is not globally routable such as a Unique Local Address (ULA) or the prefix defined in [SIDS-SRv6].¶

Failure to protect the SR-MPLS domain by correctly provisioning MPLS support per interface permits attackers from outside the domain to send packets that use the replication services provisioned within the domain.¶

Failure to protect the SRv6 domain with IACLs on external interfaces combined with failure to implement the recommendations of BCP 38 [RFC2827] or apply IACLs on nodes provisioning SIDs permits attackers from outside the SR domain to send packets that use the replication services provisioned within the domain.¶

Given the definition of the Replication segment in this document, an attacker subverting the ingress filters above cannot take advantage of a stack of Replication segments to perform amplification attacks nor link exhaustion attacks. Replication segment trees always terminate at a leaf or bud node resulting in a decapsulation. However, this does allow an attacker to inject traffic to the receivers within a P2MP service.¶

This document introduces an SR segment endpoint behavior that replicates and decapsulates an inner payload for both the MPLS and IPv6 data planes. Similar to any MPLS end-of-stack label, or SRv6 END.D* behavior, if the protections described above are not implemented, an attacker can perform an attack via the decapsulating segment (including the one described in this document).¶

Incorrect provisioning of Replication segments can result in a chain of Replication segments forming a loop. This can happen if Replication segments are provisioned on SR nodes without using a control plane. In this case, replicated packets can create a storm until MPLS TTL (for SR-MPLS) or IPv6 Hop Limit (for SRv6) decrements to zero. A control plane such as PCE can be used to prevent loops. The control plane protocols (like Path Computation Element Communication Protocol (PCEP), BGP, etc.) used to instantiate Replication segments can leverage their own security mechanisms such as encryption, authentication filtering, etc.¶

For SRv6, Section 2.2.3 describes an exception for the ICMPv6 Parameter Problem message with Code 2. If an attacker sends a packet destined to a Replication-SID with the source address of a node and with an extension header using the unknown option type marked as mandatory, then a large number of ICMPv6 Parameter Problem messages can cause a denial-of-service attack on the source node. Although this document does not specify any extension headers, any future extension of this document that does so is susceptible to this security concern.¶

If an attacker can forge an IPv6 packet with:¶

• the source address of a node,¶
• a Replication-SID as the DA, and¶
• an IPv6 Hop Limit such that nodes that forward replicated packets on an IPv6 locator unicast prefix, decrement the Hop Limit to zero,¶

then these nodes can cause a storm of ICMPv6 error packets to overwhelm the source node under attack. The IPv6 Hop Limit Threshold check described in Section 2.2 can help mitigate such attacks.¶

Appendix A. Illustration of a Replication Segment

This section illustrates an example of a single Replication segment. Examples showing Replication segments stitched together to form a P2MP tree (based on SR P2MP policy) are in [P2MP-POLICY].¶

Consider the following topology:¶

                               R3------R6
                              /         \
                      R1----R2----R5-----R7
                              \         /
                               +--R4---+

Replication segment
        <R-ID,R1>: Replication-SID: R-SID1 Replication state: R2:
        <R-SID2->L12> R6: <N-SID6, R-SID6> R7: <N-SID4,
        A-SID47, R-SID7>

Replication segment
        <R-ID,R2>: Replication-SID: R-SID2 Replication state: R2:
        <Leaf>

Replication segment
        <R-ID,R6>: Replication-SID: R-SID6 Replication state: R6:
        <Leaf>

Replication segment
        <R-ID,R7>: Replication-SID: R-SID7 Replication state: R7:
        <Leaf>

Replication segment
        <R-ID,R1>: Replication-SID: 2001:db8:cccc:1:F1::0 Replication
        state: R2: <2001:db8:cccc:2:F2::0->L12> R6:
        <2001:db8:cccc:6:F6::0> R7: <2001:db8:cccc:4:C7::0>, SL:
        <2001:db8:cccc:7:F7::0>

Replication segment
        <R-ID,R2>: Replication-SID: 2001:db8:cccc:2:F2::0 Replication
        state: R2: <Leaf>

Replication segment
        <R-ID,R6>: Replication-SID: 2001:db8:cccc:6:F6::0 Replication
        state: R6: <Leaf>

Replication segment
        <R-ID,R7>: Replication-SID: 2001:db8:cccc:7:F7::0 Replication
        state: R7: <Leaf>

Acknowledgements

The authors would like to acknowledge Siva Sivabalan, Mike Koldychev, Vishnu Pavan Beeram, Alexander Vainshtein, Bruno Decraene, Thierry Couture, Joel Halpern, Ketan Talaulikar, Darren Dukes and Jingrong Xie for their valuable inputs.¶

Authors' Addresses