RFC 8611
Label Switched Path (LSP) Ping and Traceroute Multipath Support for Link Aggregation Group (LAG) Interfaces
11. Rate-Limiting on Echo Request/Reply Messages
An LSP may be over several LAGs. Each LAG may have many member links. To exercise all the links, many echo request/reply messages will be sent in a short period. It's possible that those messages may traverse a common path as a burst. Under some circumstances, this might cause congestion at the common path. To avoid potential congestion, it is RECOMMENDED that implementations randomly delay the echo request and reply messages at the initiator LSRs and responder LSRs. Rate-limiting of ping traffic is further specified in Section 5 of [RFC8029] and Section 4.1 of [RFC6425], which apply to this document as well.12. Security Considerations
This document extends the LSP Traceroute mechanism [RFC8029] to discover and exercise L2 ECMP paths to determine problematic member link(s) of a LAG. These on-demand diagnostic mechanisms are used by an operator within an MPLS control domain. [RFC8029] reviews the possible attacks and approaches to mitigate possible threats when using these mechanisms. To prevent leakage of vital information to untrusted users, a responder LSR MUST only accept MPLS echo request messages from designated trusted sources via filtering the source IP address field of received MPLS echo request messages. As noted in [RFC8029], spoofing attacks only have a small window of opportunity. If an intermediate node hijacks these messages (i.e., causes non-delivery), the use of these mechanisms will determine the data plane is not working as it should. Hijacking of a responder node such that it provides a legitimate reply would involve compromising the node itself and the MPLS control domain. [RFC5920] provides additional MPLS network-wide operation recommendations to avoid attacks. Please note that source IP address filtering provides only a weak form of access control and is not, in general, a reliable security mechanism. Nonetheless, it is required here in the absence of any more robust mechanisms that might be used.
13. IANA Considerations
13.1. LSR Capability TLV
IANA has assigned value 4 (from the range 0-16383) for the LSR Capability TLV from the "TLVs" registry under the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry [IANA-MPLS-LSP-PING]. Type TLV Name Reference ----- -------- --------- 4 LSR Capability RFC 861113.1.1. LSR Capability Flags
IANA has created a new "LSR Capability Flags" registry. The initial contents are as follows: Value Meaning Reference ----- ------- --------- 31 D: Downstream LAG Info Accommodation RFC 8611 30 U: Upstream LAG Info Accommodation RFC 8611 0-29 Unassigned Assignments of LSR Capability Flags are via Standards Action [RFC8126].13.2. Local Interface Index Sub-TLV
IANA has assigned value 4 (from the range 0-16383) for the Local Interface Index Sub-TLV from the "Sub-TLVs for TLV Type 20" subregistry of the "TLVs" registry in the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry [IANA-MPLS-LSP-PING]. Sub-Type Sub-TLV Name Reference -------- ------------ --------- 4 Local Interface Index RFC 861113.2.1. Interface Index Flags
IANA has created a new "Interface Index Flags" registry. The initial contents are as follows: Bit Number Name Reference ---------- -------------------------------- --------- 15 M: LAG Member Link Indicator RFC 8611 0-14 Unassigned
Assignments of Interface Index Flags are via Standards Action [RFC8126]. Note that this registry is used by the Interface Index Flags field of the following sub-TLVs: o The Local Interface Index Sub-TLV, which may be present in the Downstream Detailed Mapping TLV. o The Remote Interface Index Sub-TLV, which may be present in the Downstream Detailed Mapping TLV. o The Incoming Interface Index Sub-TLV, which may be present in the Detailed Interface and Label Stack TLV.13.3. Remote Interface Index Sub-TLV
IANA has assigned value 5 (from the range 0-16383) for the Remote Interface Index Sub-TLV from the "Sub-TLVs for TLV Type 20" subregistry of the "TLVs" registry in the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry [IANA-MPLS-LSP-PING]. Sub-Type Sub-TLV Name Reference -------- ------------ --------- 5 Remote Interface Index RFC 861113.4. Detailed Interface and Label Stack TLV
IANA has assigned value 6 (from the range 0-16383) for the Detailed Interface and Label Stack TLV from the "TLVs" registry in the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry [IANA-MPLS-LSP-PING]. Type TLV Name Reference ----- -------- --------- 6 Detailed Interface and Label Stack RFC 861113.4.1. Sub-TLVs for TLV Type 6
RFC 8029 changed the registration procedures for TLV and sub-TLV registries for LSP Ping. IANA has created a new "Sub-TLVs for TLV Type 6" subregistry under the "TLVs" registry of the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry [IANA-MPLS-LSP-PING].
This registry conforms with RFC 8029. The registration procedures for this sub-TLV registry are: Range Registration Procedure Note ----- ---------------------- ----- 0-16383 Standards Action This range is for mandatory TLVs or for optional TLVs that require an error message if not recognized. 16384-31743 RFC Required This range is for mandatory TLVs or for optional TLVs that require an error message if not recognized. 31744-32767 Private Use Not to be assigned 32768-49161 Standards Action This range is for optional TLVs that can be silently dropped if not recognized. 49162-64511 RFC Required This range is for optional TLVs that can be silently dropped if not recognized. 64512-65535 Private Use Not to be assigned The initial allocations for this registry are: Sub-Type Sub-TLV Name Reference Comment -------- ------------ --------- ------- 0 Reserved RFC 8611 1 Incoming Label Stack RFC 8611 2 Incoming Interface Index RFC 8611 3-31743 Unassigned 31744-32767 RFC 8611 Reserved for Private Use 32768-64511 Unassigned 64512-65535 RFC 8611 Reserved for Private Use Note: IETF does not prescribe how the Private Use sub-TLVs are handled; however, if a packet containing a sub-TLV from a Private Use ranges is received by an LSR that does not recognize the sub-TLV, an error message MAY be returned if the sub-TLV is from the range 31744-32767, and the packet SHOULD be silently dropped if it is from the range 64511-65535.
13.4.2. Interface and Label Stack Address Types
The Detailed Interface and Label Stack TLV shares the Interface and Label Stack Address Types with the Interface and Label Stack TLV. To reflect this, IANA has updated the name of the registry from "Interface and Label Stack Address Types" to "Interface and Label Stack and Detailed Interface and Label Stack Address Types".13.5. DS Flags
IANA has assigned a new bit number from the "DS Flags" subregistry of the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry [IANA-MPLS-LSP-PING]. Note: the "DS Flags" subregistry was created by [RFC8029]. Bit number Name Reference ---------- ---------------------------------------- --------- 3 G: LAG Description Indicator RFC 861114. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 10.17487/RFC8029, March 2017, <https://www.rfc-editor.org/info/rfc8029>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
14.2. Informative References
[IANA-MPLS-LSP-PING] IANA, "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters", <https://www.iana.org/assignments/ mpls-lsp-ping-parameters/>. [IEEE802.1AX] IEEE, "IEEE Standard for Local and metropolitan area networks - Link Aggregation", IEEE Std. 802.1AX. [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>. [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, <https://www.rfc-editor.org/info/rfc6425>. [RFC7439] George, W., Ed. and C. Pignataro, Ed., "Gap Analysis for Operating IPv6-Only MPLS Networks", RFC 7439, DOI 10.17487/RFC7439, January 2015, <https://www.rfc-editor.org/info/rfc7439>.
Appendix A. LAG with Intermediate L2 Switch Issues
Several flavors of provisioning models that use a "LAG with L2 switch" and the corresponding MPLS data-plane ECMP traversal validation issues are described in this appendix.A.1. Equal Numbers of LAG Members
R1 ==== S1 ==== R2 The issue with this LAG provisioning model is that packets traversing a LAG member from Router 1 (R1) to intermediate L2 switch (S1) can get load-balanced by S1 towards Router 2 (R2). Therefore, MPLS echo request messages traversing a specific LAG member from R1 to S1 can actually reach R2 via any of the LAG members, and the sender of the MPLS echo request messages has no knowledge of this nor any way to control this traversal. In the worst case, MPLS echo request messages with specific entropies will exercise every LAG member link from R1 to S1 and can all reach R2 via the same LAG member link. Thus, it is impossible for the MPLS echo request sender to verify that packets intended to traverse a specific LAG member link from R1 to S1 did actually traverse that LAG member link and to deterministically exercise "receive" processing of every LAG member link on R2. (Note: As far as we can tell, there's not a better option than "try a bunch of entropy labels and see what responses you can get back", and that's the same remedy in all the described topologies.)A.2. Deviating Numbers of LAG Members
____ R1 ==== S1 ==== R2 There are deviating numbers of LAG members on the two sides of the L2 switch. The issue with this LAG provisioning model is the same as with the previous model: the sender of MPLS echo request messages has no knowledge of the L2 load-balancing algorithm nor entropy values to control the traversal.A.3. LAG Only on Right
R1 ---- S1 ==== R2 The issue with this LAG provisioning model is that there is no way for an MPLS echo request sender to deterministically exercise both LAG member links from S1 to R2. And without such, "receive" processing of R2 on each LAG member cannot be verified.
A.4. LAG Only on Left
R1 ==== S1 ---- R2 The MPLS echo request sender has knowledge of how to traverse both LAG members from R1 to S1. However, both types of packets will terminate on the non-LAG interface at R2. It becomes impossible for the MPLS echo request sender to know that MPLS echo request messages intended to traverse a specific LAG member from R1 to S1 did indeed traverse that LAG member.Acknowledgements
The authors would like to thank Nagendra Kumar and Sam Aldrin for providing useful comments and suggestions. The authors would like to thank Loa Andersson for performing a detailed review and providing a number of comments. The authors also would like to extend sincere thanks to the MPLS RT review members who took the time to review and provide comments. The members are Eric Osborne, Mach Chen, and Yimin Shen. The suggestion by Mach Chen to generalize and create the LSR Capability TLV was tremendously helpful for this document and likely for future documents extending the MPLS LSP Ping and Traceroute mechanisms. The suggestion by Yimin Shen to create two separate validation procedures had a big impact on the contents of this document.
Authors' Addresses
Nobo Akiya Big Switch Networks Email: nobo.akiya.dev@gmail.com George Swallow Southend Technical Center Email: swallow.ietf@gmail.com Stephane Litkowski Orange Email: stephane.litkowski@orange.com Bruno Decraene Orange Email: bruno.decraene@orange.com John E. Drake Juniper Networks Email: jdrake@juniper.net Mach(Guoyi) Chen Huawei Email: mach.chen@huawei.com