--- 1/draft-smack-mpls-rfc4379bis-04.txt 2015-10-09 12:23:09.140289535 -0700 +++ 2/draft-smack-mpls-rfc4379bis-05.txt 2015-10-09 12:23:09.492298086 -0700 @@ -2,21 +2,21 @@ Network Working Group C. Pignataro Internet-Draft N. Kumar Obsoletes: 4379 (if approved) Cisco Intended status: Standards Track S. Aldrin Expires: April 5, 2016 Google M. Chen Huawei October 3, 2015 Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures - draft-smack-mpls-rfc4379bis-04 + draft-smack-mpls-rfc4379bis-05 Abstract This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation, and mechanisms for reliably sending the echo reply. @@ -202,21 +202,20 @@ This section should be empty, and removed, prior to publication. ToDos: 1. Evaluation of which of the RFCs that updated RFC 4379 need to be incorporated into this 4379bis document. Specifically, these RFCs updated RFC 4379: 6424, 6425, 6426, 6829, 7506, and 7537. RFCs that updated RFC 4379 and are incorporated into this 4379bis, will be Obsoleted by 4379bis. 2. Review IANA Allocations - 3. Fix pending figure mis-alignments 2. Motivation When an LSP fails to deliver user traffic, the failure cannot always be detected by the MPLS control plane. There is a need to provide a tool that would enable users to detect such traffic "black holes" or misrouting within a reasonable period of time, and a mechanism to isolate faults. In this document, we describe a mechanism that accomplishes these @@ -258,22 +257,22 @@ network faults. In particular, LSP ping needs to diagnose situations where the control and data planes are out of sync. It performs this by routing an MPLS echo request packet based solely on its label stack. That is, the IP destination address is never used in a forwarding decision. In fact, the sender of an MPLS echo request packet may not know, a priori, the address of the router at the end of the LSP. Providers of MPLS-based services also need the ability to trace all of the possible paths that an LSP may take. Since most MPLS services - are based on IP unicast forwarding, these paths are subject to - equal-cost multi-path (ECMP) load sharing. + are based on IP unicast forwarding, these paths are subject to equal- + cost multi-path (ECMP) load sharing. This leads to the following requirements: 1. Although the LSP in question may be broken in unknown ways, the likelihood of a diagnostic packet being delivered to a user of an MPLS service MUST be held to an absolute minimum. 2. If an LSP is broken in such a way that it prematurely terminates, the diagnostic packet MUST NOT be IP forwarded. @@ -349,26 +348,26 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLVs ... | . . . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Version Number is currently 1. (Note: the version number is to be incremented whenever a change is made that affects the ability of - an implementation to correctly parse or process an MPLS echo - request/reply. These changes include any syntactic or semantic - changes made to any of the fixed fields, or to any Type-Length-Value - (TLV) or sub-TLV assignment or format that is defined at a certain - version number. The version number may not need to be changed if an - optional TLV or sub-TLV is added.) + an implementation to correctly parse or process an MPLS echo request/ + reply. These changes include any syntactic or semantic changes made + to any of the fixed fields, or to any Type-Length-Value (TLV) or sub- + TLV assignment or format that is defined at a certain version number. + The version number may not need to be changed if an optional TLV or + sub-TLV is added.) The Global Flags field is a bit vector with the following format: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ |V| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ One flag is defined for now, the V bit; the rest MUST be set to zero @@ -1121,22 +1120,22 @@ 0 no multipath Empty (Multipath Length = 0) 2 IP address IP addresses 4 IP address range low/high address pairs 8 Bit-masked IP IP address prefix and bit mask address set 9 Bit-masked label set Label prefix and bit mask Type 0 indicates that all packets will be forwarded out this one interface. - Types 2, 4, 8, and 9 specify that the supplied Multipath Information - will serve to exercise this path. + Types 2, 4, 8, and 9 specify that the supplied Multipath + Information will serve to exercise this path. Depth Limit The Depth Limit is applicable only to a label stack and is the maximum number of labels considered in the hash; this SHOULD be set to zero if unspecified or unlimited. Multipath Length The length in octets of the Multipath Information. @@ -1965,24 +1964,26 @@ Overall, the security needs for LSP ping are similar to those of ICMP ping. There are at least three approaches to attacking LSRs using the mechanisms defined here. One is a Denial-of-Service attack, by sending MPLS echo requests/replies to LSRs and thereby increasing their workload. The second is obfuscating the state of the MPLS data plane liveness by spoofing, hijacking, replaying, or otherwise tampering with MPLS echo requests and replies. The third is an unauthorized source using an LSP ping to obtain information about the - network. To avoid potential Denial-of-Service attacks, it is - RECOMMENDED that implementations regulate the LSP ping traffic going - to the control plane. A rate limiter SHOULD be applied to the well- - known UDP port defined below. + network. + + To avoid potential Denial-of-Service attacks, it is RECOMMENDED that + implementations regulate the LSP ping traffic going to the control + plane. A rate limiter SHOULD be applied to the well-known UDP port + defined below. Unsophisticated replay and spoofing attacks involving faking or replaying MPLS echo reply messages are unlikely to be effective. These replies would have to match the Sender's Handle and Sequence Number of an outstanding MPLS echo request message. A non-matching replay would be discarded as the sequence has moved on, thus a spoof has only a small window of opportunity. However, to provide a stronger defense, an implementation MAY also validate the TimeStamp Sent by requiring an exact match on this field. @@ -2078,22 +2078,23 @@ The valid range for TLVs and sub-TLVs is 0-65535. Assignments in the range 0-16383 and 32768-49161 are made via Standards Action as defined in [RFC5226]; assignments in the range 16384-31743 and 49162-64511 are made via "Specification Required" as defined above; values in the range 31744-32767 and 64512-65535 are for Vendor Private Use, and MUST NOT be allocated. If a TLV or sub-TLV has a Type that falls in the range for Vendor Private Use, the Length MUST be at least 4, and the first four octets MUST be that vendor's SMI Private Enterprise Number, in network octet - order. The rest of the Value field is private to the vendor. TLVs - and sub-TLVs defined in this document are the following: + order. The rest of the Value field is private to the vendor. + + TLVs and sub-TLVs defined in this document are the following: Type Sub-Type Value Field ---- -------- ----------- 1 Target FEC Stack 1 LDP IPv4 prefix 2 LDP IPv6 prefix 3 RSVP IPv4 LSP 4 RSVP IPv6 LSP 5 Not Assigned 6 VPN IPv4 prefix