Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8611

Label Switched Path (LSP) Ping and Traceroute Multipath Support for Link Aggregation Group (LAG) Interfaces

Pages: 29
Proposed Standard
Updates:  8029
Updated by:  9041
Part 3 of 3 – Pages 21 to 29
First   Prev   None

Top   ToC   RFC8611 - Page 21   prevText

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.
Top   ToC   RFC8611 - Page 22

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 8611

13.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 8611

13.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
Top   ToC   RFC8611 - Page 23
   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 8611

13.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 8611

13.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].
Top   ToC   RFC8611 - Page 24
   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.
Top   ToC   RFC8611 - Page 25

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 8611

14. 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>.
Top   ToC   RFC8611 - Page 26

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>.
Top   ToC   RFC8611 - Page 27

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.
Top   ToC   RFC8611 - Page 28

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.
Top   ToC   RFC8611 - Page 29

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