PIM Working Group Y. Liu
Internet-Draft China Mobile
Intended status: Informational M. McBride
Expires: 30 September 2025 Futurewei
Z. Zhang
ZTE
J. Xie
Huawei
C. Lin
New H3C Technologies
29 March 2025
Multicast-only Fast Reroute Based on Topology Independent Loop-free
Alternate (TI-LFA) Fast Reroute
draft-ietf-pim-mofrr-tilfa-10
Abstract
This document specifies the use of Topology Independent Loop-Free
Alternate (TI-LFA) mechanisms with Multicast Only Fast ReRoute
(MoFRR) for Protocol Independent Multicast (PIM). The TI-LFA
provides fast reroute protection for unicast traffic in IP networks
by precomputing backup paths that avoid potential failures. By
integrating TI-LFA with MoFRR, this document extends the benefits of
fast reroute mechanisms to multicast traffic, enabling enhanced
resilience and minimized packet loss in multicast networks. The
document outlines an optional approach to implement TI-LFA in
conjunction with MoFRR for PIM, ensuring that multicast traffic is
rapidly rerouted in the event of a failure.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 30 September 2025.
Liu, et al. Expires 30 September 2025 [Page 1]
Internet-Draft MoFRR based on TILFA March 2025
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
2.1. LFA for MoFRR . . . . . . . . . . . . . . . . . . . . . . 4
2.2. RLFA for MoFRR . . . . . . . . . . . . . . . . . . . . . 5
2.3. TI-LFA for MoFRR . . . . . . . . . . . . . . . . . . . . 6
3. A Solution . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Join Conflict Considerations . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 15
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
Multicast-only Fast Reroute (MoFRR), as defined in [RFC7431], offers
a mechanism to reduce multicast packet loss in the event of node or
link failures by introducing simple enhancements to multicast routing
protocols, such as Protocol Independent Multicast (PIM) [RFC7761].
However, the [RFC7431] MoFRR mechanism, which selects the secondary
multicast next-hop based solely on the loop-free alternate fast
reroute defined in [RFC7431], has limitations in certain multicast
deployment scenarios (see Section 2).
This document introduces a new mechanism for MoFRR using Topology
Independent Loop-Free Alternate (TI-LFA)
[I-D.ietf-rtgwg-segment-routing-ti-lfa] fast reroute. Unlike
conventional methods, TI-LFA is independent of network topology,
Liu, et al. Expires 30 September 2025 [Page 2]
Internet-Draft MoFRR based on TILFA March 2025
enabling broader coverage across diverse network environments. The
applicability of this mechanism extends to PIM networks, such as
scenarios where PIM operates over native IP.
The TI-LFA mechanism is designed for standard link-state Interior
Gateway Protocol (IGP) shortest path and Segment Routing (SR)
scenarios. For each destination advertised by the IGP in a network,
TI-LFA pre-installs a backup forwarding entry for the protected
destination, ready to be activated upon the detection of a link
failure used to reach that destination. This document leverages the
backup path computed by TI-LFA through the IGP as a secondary
Upstream Multicast Hop (UMH) for PIM. By sending PIM secondary Join
messages hop by hop on the TI-LFA backup path, a fast reroute backup
path can be created for PIM multicast.
The techniques described in this document are limited to protecting
links and nodes within a link-state IGP area. Protecting domain exit
routers and/or links attached to other routing domains is beyond the
scope of this document. All the Segment Identifiers (SIDs) required
are contained within the Link State Database (LSDB) of the IGP.
The approach does not alter the existing management and operation of
LFA, RLFA, and TI-LFA [RFC7916] [RFC8102]
[I-D.ietf-rtgwg-segment-routing-ti-lfa]. Also, this approach is not
affected by micro-loops [RFC5715] occurring during the network re-
converges.
Note that this document introduces an optional approach for backup
join paths, designed to enhance the protection scope of existing
multicast systems. It is fully compatible with current protocol
implementations and does not necessitate any changes to the protocols
or forwarding functions on intermediate nodes. If there is a choice
between vector and non-vector joins on the intermediate nodes, the
non-vector option should be prioritized, which implies that
protection paths will remain inactive. This document does not modify
the handling of conflicts in PIM Join messages. For guidance on
conflicts in Join attributes, please refer to Section 3.3.3 of
[RFC5384].
1.1. Terminology
This document utilizes the terminology as defined in [RFC7431] and
incorporates the concepts established in [RFC7490]. The definitions
of individual terms are not reiterated within this document.
Liu, et al. Expires 30 September 2025 [Page 3]
Internet-Draft MoFRR based on TILFA March 2025
2. Problem Statement
2.1. LFA for MoFRR
Section 3 of [RFC7431] specifies that a secondary UMH in PIM for
MoFRR is a Loop-Free Alternate (LFA). However, the conventional LFA
mechanism requires that at least one neighbor's next-hop to the
destination node is a loop-free next-hop. Due to existing
limitations of the LFA mechanism in network deployments, such as
topology dependency and incomplete destination coverage, the LFA
mechanism can only be deployed in certain network topology
environments. In specific network topologies, the secondary UMH
cannot be computed in PIM for MoFRR, preventing PIM from establishing
a standby multicast tree and thus from implementing MoFRR protection.
Consequently, the [RFC7431] MoFRR functionality in PIM is applicable
only in network topologies where LFA is feasible.
The limitations of the [RFC7431] MoFRR applicability can be
illustrated using the example network depicted in Figure 1. In this
example, the metric of the R1-R4 link is 20, the metric of the R5-R6
link is 100, and the metrics of the other links are 10. All link
metrics are bidirectional.
For multicast source S1 and receiver R, the primary path of the PIM
Join packet is R3->R2->R1, and the secondary path is R3->R4->R1,
which corresponds to the LFA path of unicast routing. In this
scenario, the [RFC7431] MoFRR operates effectively.
For multicast source S2 and receiver R, the primary path of the PIM
Join packet is R3->R2. However, an LFA does not exist. If R3 sends
the packet to R4, R4 will forward it back to R3 because the IGP
shortest path from R4 to R1 is R4->R3->R2. In this case, the
[RFC7431] MoFRR cannot calculate a secondary UMH. Similarly, for
multicast source S3 and receiver R, the [RFC7431] MoFRR mechanism is
ineffective.
Liu, et al. Expires 30 September 2025 [Page 4]
Internet-Draft MoFRR based on TILFA March 2025
10 20
[S1]----(R1)-------------(R4)
| |
| |
|10 |10
10 | |
[S2]----(R2)-------------(R3)----[R]
| 10 | 10
| |
|10 |10
10 | |
[S3]----(R5)-----(R6)----(R7)
100 10
Figure 1: Example Network Topology
2.2. RLFA for MoFRR
The Remote Loop-Free Alternate (RLFA), as defined in [RFC7490],
extends the LFA mechanism, to accommodate a broader range of network
deployments by utilizing a tunnel as an alternate path. The RLFA
requires that there exists at least one node, denoted as node N, in
the network where the fault node is neither on the path from the
source node to node N nor on the path from node N to the destination
node. The source node and the destination node are the tunnel
endpoints of the RLFA repair path.
[RFC5496] introduces the Reverse Path Forwarding (RPF) Vector
attribute, which can be included in PIM Join messages to ensure that
the path is selected based on the unicast reachability of the RPF
Vector. By combining the RLFA with the RPF Vector, a secondary
multicast tree for MoFRR can be established, thereby supporting a
wider range of network topologies compared to the [RFC7431] MoFRR
implementation with LFA.
For instance, in the network illustrated in Figure 1, the secondary
path for the PIM Join packet towards multicast source S2 cannot be
computed by the [RFC7431] MoFRR, as previously described. Utilizing
the RLFA, R3 sends the packet to R4, including an RPF Vector
containing the IP address of R1, which serves as the PQ node of R3
with respect to the protected R2-R3 link. Subsequently, R4 forwards
the packet to R1 via the R1-R4 link, in accordance with the unicast
route associated with the RPF Vector. R1 then continues to forward
the packet to R2, thereby establishing the secondary path,
R3->R4->R1->R2, using MoFRR with RLFA.
Liu, et al. Expires 30 September 2025 [Page 5]
Internet-Draft MoFRR based on TILFA March 2025
2.3. TI-LFA for MoFRR
While RLFA provides enhanced capabilities over LFA, it remains
dependent on the network topology. In the network depicted in
Figure 1, the primary path of the PIM Join packet towards multicast
source S3 is R3->R2->R5. However, an RLFA path does not exist
because the PQ node of R3 with respect to the protected link R2-R3 is
absent. If R3 sends the packet to R7 with an RPF Vector containing
the IP address of R5, R7 will forward it back to R3, as the IGP
shortest path from R7 to R5 is R7->R3->R2->R5. Similarly, if R3
sends the packet to R7 with an RPF Vector containing the IP address
of R6, R7 will forward it to R6, but R6 will then forward it back to
R7, as the IGP shortest path from R6 to R5 is R6->R7->R3->R2->R5. In
this scenario, MoFRR with RLFA is unable to compute a secondary UMH.
RLFA offers improvements over LFA but still has inherent limitations.
[I-D.ietf-rtgwg-segment-routing-ti-lfa] defines a unicast FRR
solution based on the TI-LFA mechanism. The TI-LFA mechanism allows
the expression of a backup path using an explicit path and imposes no
constraints on the network topology, thus providing a more robust FRR
mechanism. Unicast traffic can be forwarded according to an explicit
path list as an alternate path to protect unicast traffic, achieving
full coverage across various network environments.
The alternate path provided by the TI-LFA mechanism is represented as
a Segment List, which includes the NodeSID of the P-space node and
the Adjacency SIDs of the links between the P-space and Q-space
nodes. PIM can look up the corresponding node IP address in the
unicast route base according to the NodeSID and the IP addresses of
the endpoints of the corresponding link in the unicast route base
according to the Adjacency SIDs. However, multicast protocol packets
cannot be directly forwarded along the path of the Segment List.
To establish a standby multicast tree, PIM Join messages need to be
transmitted hop-by-hop. However, not all nodes and links on the
unicast alternate path are included in the Segment List. If PIM
protocol packets are transmitted solely in unicast mode, they
effectively traverse the unicast tunnel like unicast traffic and do
not pass through the intermediate nodes of the tunnel. Consequently,
the intermediate nodes on the alternate path cannot forward multicast
traffic because they lack PIM state entries. PIM must create entries
on each device hop-by-hop, generating an incoming interface and an
outgoing interface list, to form a complete end-to- end multicast
tree for forwarding multicast traffic. Therefore, simply sending PIM
Join packets using the Segment List, as done with unicast traffic, is
insufficient to establish a standby multicast tree.
Liu, et al. Expires 30 September 2025 [Page 6]
Internet-Draft MoFRR based on TILFA March 2025
3. A Solution
A secondary UMH serves as a candidate next-hop that can be used to
reach the root of a multicast tree. In this document, the secondary
UMH is derived from unicast routing, utilizing the Segment List
computed by TI-LFA.
The path information from the Segment List is incorporated into the
PIM packets to guide hop-by-hop RPF selection. The IP address
corresponding to the Node SID can be used as the segmented root node,
while the IP addresses of the interfaces at both endpoints of the
link associated with the Adjacency SID can be used as the local
upstream interface and upstream neighbor.
[RFC5496] defines the PIM RPF Vector attribute, which can carry the
node's IP address corresponding to the Node SID. Additionally,
[RFC7891] defines the explicit RPF Vector, which can carry the peer's
IP address corresponding to the Adjacency SID.
This document leverages the above RPF Vector standards, obviating the
need for PIM protocol extensions. This approach allows the
establishment of a standby multicast tree based on the Segment List
calculated by TI-LFA, thereby providing comprehensive MoFRR
protection for multicast services across diverse network
environments.
Consider a Segment List calculated by TI-LFA as (NodeSID(A),
AdjSID(A-B)). Node A belongs to the P-space, and node B belongs to
the Q-space. The IP address corresponding to NodeSID(A) can be
retrieved from the local link-state database of the IGP and assumed
to be IP-a. Similarly, the IP addresses of the two endpoints of the
link corresponding to AdjSID(A-B) can also be retrieved from the
local link-state database and assumed to be IP-La and IP-Lb.
Within the PIM process, IP-a is treated as the standard RPF Vector
Attribute and added to the PIM Join packet. IP-La is considered the
local address of the incoming interface, and IP-Lb is regarded as the
address of the upstream neighbor. Consequently, IP-Lb can be
included in the PIM Join packet as the explicit RPF Vector Attribute.
The PIM protocol initially selects the RPF incoming interface and
upstream neighbor towards IP-a and proceeds hop-by-hop to establish
the PIM standby multicast tree until reaching node A. At node A, IP-
Lb is treated as the PIM upstream neighbor. Node A identifies the
incoming interface in the unicast routing table based on IP-Lb, and
IP-Lb is used as the RPF upstream address for the PIM Join packet
directed towards node B.
Liu, et al. Expires 30 September 2025 [Page 7]
Internet-Draft MoFRR based on TILFA March 2025
Upon receiving the PIM Join packet at node B, the PIM protocol,
finding no additional RPF Vector Attributes, selects the RPF incoming
interface and upstream neighbor towards the multicast source
directly. The protocol, then, continues hop-by-hop to establish the
PIM standby multicast tree, extending to the router directly
connected to the source.
4. Illustration
This section provides an illustration of MoFRR based on TI-LFA. The
example topology is depicted in Figure 2. The metric for the R3-R4
link is 100, while the metrics for the other links are 10. All link
metrics are bidirectional.
<-----Primary Path--- (S,G) Join
[S]---(R1)---(R2)******(R6)-------[R]
| |
<--- | | |
| | | |
| | (R5) |
| | | |
| | | |
| | | |
| (R3)------(R4) |
| |
--Secondary Path--
Figure 2: Example Topology
The IP addresses and SIDs involved in the MoFRR calculation are
configured as follows:
IPv4 Data Plane (MPLS-SR [RFC8660])
Liu, et al. Expires 30 September 2025 [Page 8]
Internet-Draft MoFRR based on TILFA March 2025
Node IP Address Node SID
R4 IP4-R4 Label-R4
Link IP Address Adjacency SID
R3->R4 IP4-R3-R4 Label-R3-R4
R4->R3 IP4-R4-R3 Label-R4-R3
IPv6 Data Plane (SRv6 [RFC8986])
Node IP Address Node SID (End)
R4 IP6-R4 SID-R4
Link IP Address Adjacency SID (End.X)
R3->R4 IP6-R3-R4 SID-R3-R4
R4->R3 IP6-R4-R3 SID-R4-R3
The primary path of the PIM Join packet is R6->R2->R1, and the
secondary path is R6->R5->R4->R3->R2->R1. However, the traditional
LFA does not function properly for the secondary path because the
shortest path to R2 from R5 (or from R4) still traverses the R6-R2
link. In this scenario, R6 must calculate the secondary UMH using
the proposed MoFRR method based on TI-LFA.
According to the TI-LFA algorithm, the P-space and Q-space are
illustrated in Figure 3. The TI-LFA repair path consists of the Node
SID of R4 and the Adjacency SID of R4->R3. On the MPLS-SR data
plane, the repair segment list is (Label-R4, Label-R4-R3). On the
SRv6 data plane, the repair segment list is (SID-R4, SID-R4-R3).
........
. .
[S]---(R1)---(R2)******(R6)---[R]
. | . |
. | . +++|++++
. | . + | +
. | . + (R5) +
. | . + | +
. | . + | +
. | . + | +
. (R3)------(R4) +
. . + +
........ ++++++++
Q-Space P-Space
Figure 3: P-Space and Q-Space
In the PIM process, the IP addresses associated with the repair
segment list are retrieved from the IGP link-state database.
Liu, et al. Expires 30 September 2025 [Page 9]
Internet-Draft MoFRR based on TILFA March 2025
On the IPv4 data plane, the Node SID Label-R4 corresponds to IP4-R4,
which will be carried in the RPF Vector Attribute. The Adjacency SID
Label-R4-R3 corresponds to the local address IP4-R4-R3 and the remote
peer address IP4-R3-R4, with IP4-R3-R4 carried in the Explicit RPF
Vector Attribute.
On the IPv6 data plane, the End SID SID-R4 corresponds to IP6-R4,
which will be carried in the RPF Vector Attribute. The End.X SID
SID-R4-R3 corresponds to the local address IP6-R4-R3 and the remote
peer address IP6-R3-R4, with IP6-R3-R4 carried in the Explicit RPF
Vector Attribute.
Subsequently, R6 installs the secondary UMH using these RPF
Vectors.
+---------+
|Type = 0 |
|IP4-R4 |
+---------+ +---------+
|Type = 4 | |Type = 4 |
|IP4-R3-R4| |IP4-R3-R4|
+---------+ +---------+ No RPF Vector
R6----->R5---->R4------------>R3----->R2---->R1
Figure 4: Forwarding PIM Join Packet along Secondary Path (IPv4)
On the IPv4 data plane, the forwarding of the PIM Join packet along
the secondary path is shown in Figure 4.
R6 inserts two RPF Vector Attributes in the PIM Join packet: IP4-R4
of Type 0 (RPF Vector Attribute) and IP4-R3-R4 of Type 4 (Explicit
RPF Vector Attribute). R6 then forwards the packet along the
secondary path.
When R5 receives the packet, it performs a unicast route lookup of
the first RPF Vector IP4-R4 and sends the packet to R4.
R4, being the owner of IP4-R4, removes the first RPF Vector from the
packet and forwards it according to the next RPF Vector. R4 sends
the packet to R3 based on the next RPF Vector IP4-R3-R4, as its PIM
neighbor R3 corresponds to IP4-R3-R4.
When R3 receives the packet, as the owner of IP4-R3-R4, it removes
the RPF Vector. The packet, now devoid of RPF Vectors, is forwarded
to the source through R3->R2->R1 based on unicast routes.
Liu, et al. Expires 30 September 2025 [Page 10]
Internet-Draft MoFRR based on TILFA March 2025
After the PIM Join packet reaches R1, a secondary multicast tree,
R1->R2->R3->R4->R5->R6, is established hop-by-hop for (S, G) using
MoFRR based on TI-LFA.
+---------+
|Type = 0 |
|IP6-R4 |
+---------+ +---------+
|Type = 4 | |Type = 4 |
|IP6-R3-R4| |IP6-R3-R4|
+---------+ +---------+ No RPF Vector
R6----->R5---->R4------------>R3----->R2---->R1
Figure 5: Forwarding PIM Join Packet along Secondary Path (IPv6)
On the IPv6 data plane, the forwarding of the PIM Join packet along
the secondary path is illustrated in Figure 5. The procedure is
analogous to that of the IPv4 data plane.
5. Join Conflict Considerations
This section illustrates the resolution of PIM join conflicts. When
intermediate nodes must choose between PIM joins with an RPF Vector
attribute and those without, priority should be given to the joins
without the RPF Vector attribute. Figure 6 shows the example
topology. In this setup, the metric for the R3-R4 link is 100, while
the metrics for all other links are 10. Additionally, all link
metrics are bidirectional.
<---(1)-Primary Path--- (S,G) Join
[S]---(R1)---(R2)******(R6)-------[Receiver1]
| | ^
<--- | | | |
| | | | |
| | (R5) | |
| | | (3)-(S,G) Join |
| | | | |
| | | | |
| (R3)------(R4)--[Receiver2] |
| |
+-(2)-Secondary Path--(S,G)----+
(1): Receiver1 Primary Path PIM Join (2): Receiver1
Secondary Path PIM Join with RPF Vector (3): Receiver2
Primary Path PIM Join
Figure 6: Join Conflict Scenario
Liu, et al. Expires 30 September 2025 [Page 11]
Internet-Draft MoFRR based on TILFA March 2025
Figure 6 illustrates that both R6 and R4 have receivers, with R6
utilizing MoFRR based on TI-LFA. At R6 the primary PIM Join packet
path is R6->R2->R1, while the secondary path is
R6->R5->R4->R3->R2->R1. At R4 the PIM Join packet path is
R4->R5->R6->R2->R1.
On R5, the PIM forwarding entries are:
[R5]:
(S,G) Entry 1 from Receiver1:
Incoming interface: R4-R5
Outgoing interface: R5-R6 (Join with RPF Vector)
(S,G) Entry 2 from Receiver2:
Incoming interface: R6-R5
Outgoing interface: R5-R4 (Join without RPF Vector)
To prevent conflicts, the PIM Join without the RPF Vector should be
prioritized. Thus, R5 retains only Entry 2 with R6-R5 as the
incoming interface and R5-R4 as the outgoing interface. After
selection, the final forwarding entry on R5 is as follows:
[R5]:
(S,G) active forwarding Entry:
Incoming interface: R6-R5
Outgoing interface: R5-R4
When using the proposed optional approach for backup join paths in
this document, in the event of PIM Join conflicts, Join messages
without the RPF Vector attribute are prioritized to ensure that the
original PIM forwarding functionality remains unaffected.
6. IANA Considerations
This document has no IANA actions.
Liu, et al. Expires 30 September 2025 [Page 12]
Internet-Draft MoFRR based on TILFA March 2025
7. Security Considerations
This document does not introduce additional security concerns. It
does not change the security properties of PIM. For general PIM-SM
protocol security considerations, see [RFC7761]. The security
considerations of LFA, R-LFA, and MoFRR described in [RFC5286],
[RFC7490], and [RFC7431] should apply to this document.
When deploying TI-LFA, packets may be sent over nodes and links they
were not transported through before, potentially raising the
following security issues:
1. Spoofing and False Route Advertisements
* Dependencies of LFA/R-LFA/TI-LFA on Routing Information
- LFAs depend on accurate routing information to determine
alternate paths. If an attacker can inject false routing
information (e.g., by spoofing link-state advertisements),
it could cause the network to select suboptimal or
malicious paths for LFAs.
- R-LFA and TI-LFA also depend on accurate routing
information, particularly for determining the tunneling
paths or explicit paths. False route advertisements could
mislead the network into using insecure or compromised
paths.
2. On-path Attacks
* Use of Alternate Paths
- By rerouting traffic through alternate paths, especially
those that traverse multiple hops (as in R-LFA and TI-LFA),
the risk of On-path attacks increases if any of the
intermediate routers on the alternate path is compromised.
- TI-LFA, which uses explicit paths, might expose traffic to
routers that were not originally part of the primary path,
potentially allowing for interception or alteration of the
traffic.
3. Confidentiality and Integrity
* Traffic Encapsulation
Liu, et al. Expires 30 September 2025 [Page 13]
Internet-Draft MoFRR based on TILFA March 2025
- R-LFA and TI-LFA involve encapsulating traffic, which may
expose it to vulnerabilities if the encapsulation
mechanisms are not secure. For instance, if IPsec or
another secure encapsulation method is not used, an
attacker might be able to intercept or alter the traffic in
transit.
* Protection of Explicit Paths
- TI-LFA relies on explicit paths that are typically defined
using segment routing. If these paths are not properly
protected, an attacker could manipulate the segment list to
reroute traffic through malicious nodes.
4. Increased Attack Surface
* Extended Topology
- By introducing LFA, R-LFA, and TI-LFA, the network
increases its reliance on additional routers and links,
thereby expanding the potential attack surface. Compromise
of any router in these alternate paths could expose traffic
to unauthorized access or disruption.
To address security issues #1 and #2 mentioned above, control plane
protocols need to provide security protection. To mitigate the risks
associated with false route advertisements and On-path attacks, it is
recommended to use secure routing protocols (e.g., OSPFv3 with IPsec,
ISIS HMAC-SHA256, or PIM with IPsec) that provide authentication and
integrity protection for routing updates.
To address security issues #3 and #4 mentioned above, these
mechanisms need to run within a trusted network. The security of
LFA, R-LFA, and TI-LFA mechanisms heavily relies on the
trustworthiness of the underlying routing infrastructure. As the
solution described in the document is based on Segment Routing
technology, readers should be aware of the security considerations
related to this technology ([RFC8402]) and its data plane
instantiations ([RFC8660], [RFC8754], and [RFC8986]).
8. References
8.1. Normative References
[I-D.ietf-rtgwg-segment-routing-ti-lfa]
Bashandy, A., Litkowski, S., Filsfils, C., Francois, P.,
Decraene, B., and D. Voyer, "Topology Independent Fast
Reroute using Segment Routing", Work in Progress,
Liu, et al. Expires 30 September 2025 [Page 14]
Internet-Draft MoFRR based on TILFA March 2025
Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-
21, 12 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-
segment-routing-ti-lfa-21>.
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
IP Fast Reroute: Loop-Free Alternates", RFC 5286,
DOI 10.17487/RFC5286, September 2008,
<https://www.rfc-editor.org/info/rfc5286>.
[RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol
Independent Multicast (PIM) Join Attribute Format",
RFC 5384, DOI 10.17487/RFC5384, November 2008,
<https://www.rfc-editor.org/info/rfc5384>.
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
Forwarding (RPF) Vector TLV", RFC 5496,
DOI 10.17487/RFC5496, March 2009,
<https://www.rfc-editor.org/info/rfc5496>.
[RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B.
Decraene, "Multicast-Only Fast Reroute", RFC 7431,
DOI 10.17487/RFC7431, August 2015,
<https://www.rfc-editor.org/info/rfc7431>.
[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
RFC 7490, DOI 10.17487/RFC7490, April 2015,
<https://www.rfc-editor.org/info/rfc7490>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC7891] Asghar, J., Wijnands, IJ., Ed., Krishnaswamy, S., Karan,
A., and V. Arya, "Explicit Reverse Path Forwarding (RPF)
Vector", RFC 7891, DOI 10.17487/RFC7891, June 2016,
<https://www.rfc-editor.org/info/rfc7891>.
[RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K.,
Horneffer, M., and P. Sarkar, "Operational Management of
Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916,
July 2016, <https://www.rfc-editor.org/info/rfc7916>.
8.2. Informative References
Liu, et al. Expires 30 September 2025 [Page 15]
Internet-Draft MoFRR based on TILFA March 2025
[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free
Convergence", RFC 5715, DOI 10.17487/RFC5715, January
2010, <https://www.rfc-editor.org/info/rfc5715>.
[RFC8102] Sarkar, P., Ed., Hegde, S., Bowers, C., Gredler, H., and
S. Litkowski, "Remote-LFA Node Protection and
Manageability", RFC 8102, DOI 10.17487/RFC8102, March
2017, <https://www.rfc-editor.org/info/rfc8102>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
Contributors
Mengxiao Chen
New H3C Technologies
China
Email: chen.mengxiao@h3c.com
Authors' Addresses
Yisong Liu
China Mobile
China
Email: liuyisong@chinamobile.com
Liu, et al. Expires 30 September 2025 [Page 16]
Internet-Draft MoFRR based on TILFA March 2025
Mike McBride
Futurewei Inc.
USA
Email: michael.mcbride@futurewei.com
Zheng(Sandy) Zhang
ZTE Corporation
China
Email: zzhang_ietf@hotmail.com
Jingrong Xie
Huawei Technologies
China
Email: xiejingrong@huawei.com
Changwang Lin
New H3C Technologies
China
Email: linchangwang.04414@h3c.com
Liu, et al. Expires 30 September 2025 [Page 17]