--- 1/draft-ietf-mpls-lsp-ping-relay-reply-04.txt 2014-11-14 06:14:53.372280484 -0800 +++ 2/draft-ietf-mpls-lsp-ping-relay-reply-05.txt 2014-11-14 06:14:53.404281267 -0800 @@ -1,23 +1,23 @@ Network Working Group J. Luo, Ed. Internet-Draft ZTE Updates: 4379 (if approved) L. Jin, Ed. Intended status: Standards Track -Expires: January 31, 2015 T. Nadeau, Ed. +Expires: May 18, 2015 T. Nadeau, Ed. Lucidvision G. Swallow, Ed. Cisco - July 30, 2014 + November 14, 2014 Relayed Echo Reply mechanism for LSP Ping - draft-ietf-mpls-lsp-ping-relay-reply-04 + draft-ietf-mpls-lsp-ping-relay-reply-05 Abstract In some inter autonomous system (AS) and inter-area deployment scenarios for RFC 4379 "Label Switched Path (LSP) Ping and Traceroute", a replying LSR may not have the available route to the initiator, and the Echo Reply message sent to the initiator would be discarded resulting in false negatives or complete failure of operation of LSP Ping and Traceroute. This document describes extensions to LSP Ping mechanism to enable the replying Label @@ -33,21 +33,21 @@ 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 http://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 January 31, 2015. + This Internet-Draft will expire on May 18, 2015. Copyright Notice Copyright (c) 2014 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -68,59 +68,65 @@ not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.1. Relayed Echo Reply message . . . . . . . . . . . . . . . 5 + 3.1. Relayed Echo Reply message . . . . . . . . . . . . . . . 6 3.2. Relay Node Address Stack . . . . . . . . . . . . . . . . 6 - 3.3. New Return Code . . . . . . . . . . . . . . . . . . . . . 7 + 3.3. New Return Code . . . . . . . . . . . . . . . . . . . . . 8 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 8 4.2. Receiving an Echo Request . . . . . . . . . . . . . . . . 8 4.3. Originating an Relayed Echo Reply . . . . . . . . . . . . 9 4.4. Relaying an Relayed Echo Reply . . . . . . . . . . . . . 9 4.5. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 10 4.6. Receiving an Echo Reply . . . . . . . . . . . . . . . . . 10 4.7. Impact to Traceroute . . . . . . . . . . . . . . . . . . 10 - 5. LSP Ping Relayed Echo Reply Example . . . . . . . . . . . . . 10 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 12 + 5. LSP Ping Relayed Echo Reply Example . . . . . . . . . . . . . 11 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8.1. New Message Type . . . . . . . . . . . . . . . . . . . . 13 - 8.2. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 8.3. New Return Code . . . . . . . . . . . . . . . . . . . . . 13 + 8.2. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 8.3. New Return Code . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 - 11.2. Informative References . . . . . . . . . . . . . . . . . 14 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 + 11.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction This document describes the extensions to the Label Switched Path (LSP) Ping as specified in [RFC4379], by adding a relayed echo reply mechanism which could be used to detect data plane failures for the inter autonomous system (AS) and inter-area LSPs. The extensions are to update the [RFC4379]. Without these extensions, the ping functionality provided by [RFC4379] would fail in many deployed inter-AS scenarios, since the replying LSR in one AS may not have the available route to the initiator in the other AS. The mechanism in this document defines a new message type referred as "Relayed Echo Reply message", and a new TLV referred as "Relay Node Address Stack TLV". + This document is also to update [RFC4379], include updating of Echo + Request sending procedure in section 4.3 of [RFC4379], Echo Request + receiving procedure in section 4.4 of [RFC4379], Echo Reply sending + procedure in Section 4.5 of [RFC4379], Echo Reply receiving procedure + in section 4.6 of [RFC4379]. + 1.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Motivation LSP Ping [RFC4379] defines a mechanism to detect the data plane failures and localize faults. The mechanism specifies that the Echo @@ -129,27 +135,31 @@ administrative domains where IP addresses reachability are allowed among LSRs, and every LSR is able to route back to the originating LSR. However, in practice, this is often not the case due to intra- provider routing policy, route hiding, and network address translation at autonomous system border routers (ASBR). In fact, it is almost uniformly the case that in inter-AS scenarios, it is not allowed the distribution or direct routing to the IP addresses of any of the nodes other than the ASBR in another AS. Figure 1 demonstrates a case where one LSP is set up between PE1 and - PE2. If private addresses were in use within AS1, a traceroute from - PE1 directed to PE2 could fail if the fault exists somewhere between - ASBR2 and PE2. Because P2 cannot forward packets back to PE1 given - that it is a private address within AS1. In this case, PE1 would - detect a path break, as the Echo Reply messages would not be - received. Then localization of the actual fault would not be - possible. + PE2. If PE1's IP address is not distributed to AS2, a traceroute + from PE1 directed to PE2 could fail if the fault exists somewhere + between ASBR2 and PE2. Because P2 cannot forward packets back to PE1 + given that it is an routable IP address in AS1 but not routable in + AS2. In this case, PE1 would detect a path break, as the Echo Reply + messages would not be received. Then localization of the actual + fault would not be possible. + + Note that throughout the document, routable address means that it is + possible to route an IP packet to this address using the normal + information exchanged by the IGP operating in the AS +-------+ +-------+ +------+ +------+ +------+ +------+ | | | | | | | | | | | | | PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 | | | | | | | | | | | | | +-------+ +-------+ +------+ +------+ +------+ +------+ <---------------AS1-------------><---------------AS2------------> <---------------------------- LSP ------------------------------> Figure 1: Simple Inter-AS LSP Configuration @@ -172,26 +182,26 @@ \ | | | | | | \| | +--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN | | | | | | | | +-------+ +-------+ +------+ +------+ static route ISIS L1 LDP ISIS L2 LDP <-Access-><--Aggregation Domain--><---------Core---------> Figure 2: Seamless MPLS Architecture This document describes extensions to the LSP Ping mechanism to - facilitate a response from the replying LSR, by defining a simple - mechanism that uses a relay node (e.g, ASBR) to relay the message - back to the initiator. Every designated or learned relay node must - have an IP route to the next relay node or to the initiator. Using a - recursive approach, relay node could relay the message to the next - relay node until the initiator is reached. + facilitate a response from the replying LSR, by defining a mechanism + that uses a relay node (e.g, ASBR) to relay the message back to the + initiator. Every designated or learned relay node must be reachable + to the next relay node or to the initiator. Using a recursive + approach, relay node could relay the message to the next relay node + until the initiator is reached. The LSP Ping relay mechanism in this document is defined for unicast case. How to apply the LSP Ping relay mechanism in multicast case is out of the scope. 3. Extensions [RFC4379] describes the basic MPLS LSP Ping mechanism, which defines two message types, Echo Request and Echo Reply message. This document defines a new message, Relayed Echo Reply message. This new @@ -250,23 +260,23 @@ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Relay Node Address Stack TLV - Type: to be assigned by IANA. A value should be assigned from 32768-49161 as suggested by [RFC4379] Section 3. - Length: the length of the value field in octets. - - Initiator Source Port: the source UDP port that the initiator - sends the Echo Request message, and also the port that is expected - to receive the Echo Reply message. + - Initiator Source Port: the source UDP port that the initiator uses + in the Echo Request message, and also the port that is expected to + receive the Echo Reply message. - Number of Relayed Addresses: an integer indicating the number of relayed addresses in the stack. - Stack of Relayed Addresses: a list of relay node addresses. The format of each relay node address is as below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 @@ -282,28 +292,30 @@ 1 IPv4 4 2 IPv6 16 Reserved: This field is reserved and MUST be set to zero. K bit: if the K bit is set to 1, then this sub-TLV MUST be kept in Relay Node Address Stack during TLV compress process described in section 4.2. The entry with Unspecified Address Type SHOULD NOT set K bit. - Having the K bit set on the relay node address entry causes that + Having the K bit set in the relay node address entry causes that entry to be preserved in the Relay Node Address Stack TLV for the entire traceroute operation. A responder node MAY set the K bit to ensure its relay node address entry remains as one of the relay nodes - in the Relay Node Address Stack TLV. Some nodes could be configured - to always set the K bit, or the module handling MPLS echo requests - could discover its K bit use through topology awareness. How a node - determines to set the K bit is outside the scope of this document. + in the Relay Node Address Stack TLV. The address with K bit set will + always be a relay node address for the Relayed Echo Reply, see + section 4.3. Some nodes could be configured to always set the K bit, + or the module handling MPLS echo requests could discover its K bit + use through topology awareness. One application scenario of K bit is + given out in section 5. Relayed Address: this field specifies the node address, either IPv4 or IPv6. 3.3. New Return Code A new Return Code is used by the replying LSR to notify the initiator that the packet length is exceeded unexpected by the Relay Node Address Stack TLV. @@ -331,121 +343,118 @@ message. 4.2. Receiving an Echo Request In addition to the processes in section 4.4 of [RFC4379], the procedures of the Relay Node Address Stack TLV are defined here. Upon receiving a Relay Node Address Stack TLV of the Echo Request message, the receiver MUST check the addresses of the stack in sequence from top to bottom (the first address in the stack will be - the first one to be checked), to find out the first public routable - IP address. Those address entries behind of the first routable IP + the first one to be checked), to find out the first routable IP + address. Those address entries behind of the first routable IP address in the address list with K bit set to 0 MUST be deleted, and the address entry of the replying LSR MUST be added at the bottom of the stack. The address entry added by the replying LSR MUST be same as the source IP address of Relay Echo Reply (section 4.3) or Echo - Reply message (section 4.5) being sent. Those address entries with K - bit set to 1 MUST be kept in the stack. The updated Relay Node - Address Stack TLV MUST be carried in the response message. + Reply message (section 4.5) being sent. A second or more address + entries could also be added if necessary, which depends on + implementation. Those address entries with K bit set to 1 MUST be + kept in the stack. The updated Relay Node Address Stack TLV MUST be + carried in the response message. If the replying LSR is configured to hide its routable address information, the address entry added in the stack SHOULD be a blank entry with Address Type set to unspecified. The blank address entry in the receiving Echo Request SHOULD be treated as an unroutable address entry. If the packet length was exceeded unexpectedly by the Relay Node Address Stack TLV, the TLV SHOULD be returned back unchanged in the Echo Reply message. And the new return code in section 3.3 SHOULD be used to notify the initiator of the situation. - If the first routable IP address is the first address in the stack, - the replying LSR SHOULD respond an Echo Reply message to the - initiator. - - If the first routable IP address is an intermediate node, other than - the first address in the stack, the replying LSR SHOULD send a - Relayed Echo Reply instead of an Echo Reply as a response. - An LSR not recognize the Relay Node Address Stack TLV, SHOULD ignore it according to section 3 of [RFC4379]. 4.3. Originating an Relayed Echo Reply - When the replying LSR receives an Echo Request with the first IP - address in the Relay Node Address Stack TLV is IP unroutable, the - replying LSR SHOULD send a Relayed Echo Reply message to the first - routable intermediate node. The processing of Relayed Echo Reply is - the same with the procedure of the Echo Reply described in + To find out the next relay node address, the node SHOULD check the + address items in Relay Node Address Stack TLV in sequence from top to + down, and find the first IP routable address, e.g., A, and the last + address with K bit set, e.g., B. If address A is before address B in + Relay Node Address Stack TLV, then use address B as the next relay + node address. Otherwise, use address A as the next relay node + address. If there is no B existed, then use A as the next relay node + address. + + When the replying LSR receives an Echo Request, and the first IP + address in the Relay Node Address Stack TLV is not the next relay + node address, the replying LSR SHOULD send a Relayed Echo Reply + message to the next relay node. The processing of Relayed Echo Reply + is the same with the procedure of the Echo Reply described in Section 4.5 of [RFC4379], except the destination IP address and the destination UDP port. The destination IP address of the Relayed Echo - Reply is set to the first routable IP address from the Relay Node + Reply is set to the next relay node address from the Relay Node Address Stack TLV, and both the source and destination UDP port is - set to 3503. + set to 3503. The updated Relay Node Address Stack TLV described in + section 4.2 MUST be carried in the Relayed Echo Reply message. 4.4. Relaying an Relayed Echo Reply Upon receiving an Relayed Echo Reply message with its own address as - the destination address in the IP header, the relay node SHOULD check - the address items in Relay Node Address Stack TLV in sequence from - top to down, and find the first routable node address. - - If the first routable address is the top one of the address list, - e.g, the initiator address, the relay node SHOULD send an Echo Reply - message to the initiator containing the same payload with the Relayed - Echo Reply message received. See section 4.5 for detail. + the destination address in the IP header, the relay node SHOULD find + out the next relay node address as described in section 4.3. - If the first routable address is not the top one of the address list, - e.g, another intermediate relay node, the relay node SHOULD send an - Relayed Echo Reply message to this relay node with the payload - unchanged. The TTL of the Relayed Echo Reply SHOULD be copied from - the received Relay Echo Reply and decremented by 1. + If the next relay node address is not the first one in the address + list, e.g, another intermediate relay node, the relay node SHOULD + send an Relayed Echo Reply message to this next relay node with the + payload unchanged. The TTL of the Relayed Echo Reply SHOULD be + copied from the received Relay Echo Reply and decremented by 1. - Note, the replying LSR SHOULD send a Relayed Echo Reply message to - the first relay node found in Relay Node Address Stack TLV that is IP - routable. The routable address MUST be located before the source IP - address of the received Relayed Echo Reply which must be also in the - stack, otherwise the Relayed Echo Reply SHOULD not be sent, so as to - avoid potential loop. + Note, the next relay node address MUST be located before the source + IP address of the received Relayed Echo Reply which MUST be also in + the stack, otherwise the Relayed Echo Reply SHOULD NOT be sent, so as + to avoid potential loop. 4.5. Sending an Echo Reply The Echo Reply is sent in two cases: - 1. When the replying LSR receives an Echo Request with the first IP - address in the Relay Node Address Stack TLV IP routable, the replying - LSR would send an Echo Reply to the initiator. In addition to the - procedure of the Echo Reply described in Section 4.5 of [RFC4379], - the Relay Node Address Stack TLV would be carried in the Echo Reply. + 1. When the replying LSR receives an Echo Request, and the first IP + address in the Relay Node Address Stack TLV is the next relay node + address (section 4.3), the replying LSR would send an Echo Reply to + the initiator. In addition to the procedure of the Echo Reply + described in Section 4.5 of [RFC4379], the updated Relay Node Address + Stack TLV described in section 4.2 MUST be carried in the Echo Reply. - 2. When the intermediate relay node receives a Relayed Echo Reply - with the first IP address in the Relay Node Address Stack TLV IP - routable, the intermediate relay node would send the Echo Reply to - the initiator with the UDP payload unchanged other than the Message - Type field (change from type of Relayed Echo Reply to Echo Reply). - The destination IP address of the Echo Reply is set to the first IP - address in the stack, and the destination UDP port would be copied - from the Initiator Source Port field of the Relay Node Address Stack - TLV. The source UDP port should be 3503. The TTL of the Echo Reply - SHOULD be copied from the received Relay Echo Reply and decremented - by 1. + 2. When the intermediate relay node receives a Relayed Echo Reply, + and the first IP address in the Relay Node Address Stack TLV is the + next relay node address (section 4.3), the intermediate relay node + would send the Echo Reply to the initiator with the UDP payload + unchanged other than the Message Type field (change from type of + Relayed Echo Reply to Echo Reply). The destination IP address of the + Echo Reply is set to the first IP address in the stack, and the + destination UDP port would be copied from the Initiator Source Port + field of the Relay Node Address Stack TLV. The source UDP port + should be 3503. The TTL of the Echo Reply SHOULD be copied from the + received Relay Echo Reply and decremented by 1. 4.6. Receiving an Echo Reply In addition to the processes in Section 4.6 of [RFC4379], the initiator would copy the Relay Node Address Stack TLV received in the Echo Reply to the next Echo Request. 4.7. Impact to Traceroute - Source IP address in Echo Reply and Relay Echo Reply are to be of the + Source IP address in Echo Reply and Relay Echo Reply is to be of the address of the node sending those packets, not the original responding node. Then the traceroute address output module will print the source IP address as below: if (Relay Node Address Stack TLV exists) { Print the last address in the stack; } else { Print the source IP address of Echo Reply message; } @@ -481,54 +490,65 @@ address following PE1 address. As a result, there would be PE1's address followed by ASBR1's address in the Relay Node Address Stack TLV of the Echo Reply sent by ASBR1. PE1 then sends an Echo Request with outer-most label TTL=3, containing the Relay Node Address Stack TLV copied from the received Echo Reply message. Upon receiving the Echo Request message, ASBR2 checks the address list in the Relay Node Address Stack TLV in sequence, and finds out that PE1's address is IP route unreachable, and ASBR1's address is the first routable one in the Relay Node - Address Stack TLV. ASBR2 adds its address as the last address item - following ASBR1's address in Relay Node Address Stack TLV, sets - ASBR1's address as the destination address of the Relayed Echo Reply, - and sends the Relayed Echo Reply to ASBR1. + Address Stack TLV. So ASBR1 is the next relay node. ASBR2 adds its + address as the last address item following ASBR1's address in Relay + Node Address Stack TLV, sets ASBR1's address as the destination + address of the Relayed Echo Reply, and sends the Relayed Echo Reply + to ASBR1. Upon receiving the Relayed Echo Reply from ASBR2, ASBR1 checks the address list in the Relay Node Address Stack TLV in sequence, and finds out that PE1's address is first routable one in the address - list. Then ASBR1 sends an Echo Reply to PE1 with the payload of the - received Relayed Echo Reply no changes other than the Message Type - field. + list. So PE1 is the next relay node. Then ASBR1 sends an Echo Reply + to PE1 with the payload of the received Relayed Echo Reply unchanged + other than the Message Type field. For the Echo Request with outer-most label TTL=4, P2 checks the address list in the Relay Node Address Stack TLV in sequence, and finds out that both PE1's and ASBR1's addresses are not IP routable, and ASBR2's address is the first routable address. Then P2 sends an Relayed Echo Reply to ASBR2 with the Relay Node Address Stack TLV containing four addresses, PE1's, ASBR1's, ASBR2's and P2's address in sequence. Then according to the process described in section 4.4, ASBR2 sends the Relayed Echo Reply to ASBR1. Upon receiving the Relayed Echo - Reply, ASBR1 sends an Echo Reply to PE1 which is routable. And as + Reply, ASBR1 sends an Echo Reply to PE1 which is IP routable. And as relayed by ASBR2 and ASBR1, the Echo Reply would finally be sent to the initiator PE1. For the Echo Request with outer-most label TTL=5, the Echo Reply would relayed to PE1 by ASBR2 and ASBR1, similar to the case of TTL=4. The Echo Reply from the replying node which has no IP reachable route to the initiator is finally transmitted to the initiator by multiple relay nodes. + In the case that the interface address of ASBR1 to P1 is IP1 which + maybe an IPv4 private address and not IP routable for AS2, and the + loopback address on ASRB1 is IP2 which is routable for AS2. Then + when ASBR1 sends a Relayed Echo Reply, it will firstly add IP1 + without K bit set in the Relay Node Address Stack TLV, and then add + IP2 with K bit set in the stack TLV. Then ASBR2/P2 could relay the + Relayed Echo Reply back first to IP2 which is routable for ASBR2/P2, + then ASBR1 will send Echo Reply to PE1. Thanks for the K bit, the + ASBR1 will not be skipped for message relay. + 6. Security Considerations The Relayed Echo Reply mechanism for LSP Ping creates an increased risk of DoS by putting the IP address of a target router in the Relay Node Address Stack. These messages then could be used to attack the control plane of an LSR by overwhelming it with these packets. A rate limiter SHOULD be applied to the well-known UDP port on the relay node as suggested in [RFC4379]. The node which acts as a relay node SHOULD validate the relay reply against a set of valid source addresses and discard packets from untrusted border router addresses. @@ -597,39 +617,35 @@ TBD Response Packet length was exceeded unexpected by the Relay Node Address Stack TLV unexpected The value should be assigned from the "Standards Action" range (0-191), and using the lowest free value within this range. 9. Acknowledgement The authors would like to thank Carlos Pignataro, Xinwen Jiao, Manuel Paul, Loa Andersson, Wim Henderickx, Mach Chen, Thomas Morin, Gregory - Mirsky, and Nobo Akiya for their valuable comments and suggestions. + Mirsky, Nobo Akiya and Joel M. Halpern for their valuable comments + and suggestions. 10. Contributors Ryan Zheng JSPTPD 371, Zhongshan South Road Nanjing, 210006, China Email: ryan.zhi.zheng@gmail.com 11. References 11.1. Normative References - [I-D.ietf-mpls-proxy-lsp-ping] - Swallow, G., Lim, V., and S. Aldrin, "Proxy MPLS Echo - Request", draft-ietf-mpls-proxy-lsp-ping-02 (work in - progress), July 2014. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. 11.2. Informative References [I-D.ietf-mpls-seamless-mpls]