idnits 2.17.1 draft-ietf-mpls-lsp-ping-ttl-tlv-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 30, 2014) is 3551 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC2119' on line 123 -- Looks like a reference, but probably isn't: 'RFC4379' on line 261 == Unused Reference: '1' is defined on line 288, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 291, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 295, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4379 (ref. '1') (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Sami Boutros 3 INTERNET-DRAFT Siva Sivabalan 4 Intended Status: Standards Track George Swallow 5 Shaleen Saxena 6 Cisco Systems 8 Vishwas Manral 9 Hewlett Packard Co. 11 Sam Aldrin 12 Huawei Technologies, Inc. 14 Expires: January 31, 2015 July 30, 2014 16 Definition of Time-to-Live TLV for LSP-Ping Mechanisms 17 draft-ietf-mpls-lsp-ping-ttl-tlv-08.txt 19 Abstract 21 LSP-Ping is a widely deployed Operation, Administration, and 22 Maintenance (OAM) mechanism in MPLS networks. However, in the present 23 form, this mechanism is inadequate to verify connectivity of a 24 segment of a Multi-Segment PseudoWire (MS-PW) and/or bidirectional 25 co-routed LSP from any node on the path of the MS-PW and/or 26 bidirectional co-routed LSP. This document defines a TLV to address 27 this shortcoming. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as 37 Internet-Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/1id-abstracts.html 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 Copyright and License Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Time To Live TLV . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. TTL TLV Format . . . . . . . . . . . . . . . . . . . . . . 4 71 3.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 4.1. Traceroute mode . . . . . . . . . . . . . . . . . . . . . . 6 74 4.2. Error scenario . . . . . . . . . . . . . . . . . . . . . . 6 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 8.1 Normative References . . . . . . . . . . . . . . . . . . . 7 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 82 1. Introduction 84 A MS-PW may span across multiple service provider networks. In order 85 to allow Service Providers (SP) to verify segments of such MS-PW from 86 any node on the path of the MS-PW, any node along the path of the MS- 87 PW, should be able to originate an MPLS Echo Request packet to any 88 other node along the path of the MS-PW and receive the corresponding 89 MPLS Echo Reply. If the originator of the MPLS Echo Request is at the 90 end of a MS-PW, the receiver of the request can send the reply back 91 to the sender without knowing the hop-count distance of the 92 originator. The reply will be intercepted by the originator 93 regardless of the TTL value on the reply packet. But, if the 94 originator is not at the end of the MS-PW, the receiver of the MPLS 95 Echo Request MAY need to know how many hops away the originator of 96 the MPLS Echo Request is so that it can set the TTL value on the MPLS 97 header for the MPLS Echo Reply to be intercepted at the originator 98 node. 100 In MPLS networks, for bidirectional co-routed LSPs, if it is desired 101 to verify connectivity from any intermediate node (LSR) on the LSP to 102 the any other LSR on the LSP the receiver may need to know the TTL to 103 send the MPLS Echo Reply with, so as the packet is intercepted by the 104 originator node. 106 A new optional TTL TLV is defined in this document. This TLV will be 107 added by the originator of the MPLS Echo Request to inform the 108 receiver how many hops away the originator is on the path of the MS- 109 PW or Bidirectional LSP. 111 This mechanism only works if the MPLS Echo Reply is sent down the co- 112 routed LSP, hence the scope of this TTL TLV is currently limited to 113 MS-PW or Bidirectional co-routed MPLS LSPs. The presence of the TLV 114 implies the use of the return path of the co-routed LSP, if the 115 return path is any other mechanism then the TLV in the MPLS Echo 116 Request MUST be ignored. 118 2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 LSR: Label Switching Router 126 MPLS-TP: MPLS Transport Profile 128 MS-PW: Multi-Segment Pseudowire 129 PW: Pseudowire 131 TLV: Type Length Value 133 TTL: Time To Live 135 3. Time To Live TLV 137 3.1. TTL TLV Format 139 0 1 2 3 140 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 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Type = TBD | Length = 8 | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Value | Reserved | Flags | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 Figure 1: Time To Live TLV format 148 The TTL TLV has the format shown in Figure 1. 150 Value 152 The value of the TTL as specified by this TLV 154 Flags 156 The Flags field is a bit vector with the following format: 158 0 1 159 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | MBZ |R| 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 One flag is defined for now, the R flag; the rest of the 165 flags are currently undefined and MUST be zero (MBZ) when 166 sending and ignored on receipt. 168 The R flag (Reply TTL) is set signify that the value is 169 meant to be used as the TTL for the reply packet. Other bits 170 may be defined later to enhance the scope of this TLV. 172 3.2. Usage 174 This TLV SHALL be included in the MPLS Echo Request by the originator 175 of request. The use of this TLV is optional. If a receiver does not 176 understand the TTL TLV, it will simply ignore the TLV (Type value of 177 TLV is assumed to be in the range of optional TLV's which SHOULD be 178 ignored if an implementation does not support or understand them). In 179 the absence of TTL TLV or if TTL TLV is ignored by a receiver, the 180 determination of the TTL value used in the MPLS label on the LSP-Ping 181 echo reply is beyond the scope of this document. 183 If a receiver understands the TTL TLV, and the TTL TLV is present in 184 the MPLS Echo Request, and if the value field is zero, the LSP-Ping 185 echo request packet SHOULD be dropped. 187 If a receiver understands the TTL TLV, and the TTL TLV is present in 188 the MPLS Echo Request, the receiver MUST use the TTL value specified 189 in TLV in the MPLS header of the MPLS Echo Reply. In other words, if 190 the value of the TTL provided by this TLV does not match the TTL 191 determined by other means, such as Switching Point TLV in MS-PW, then 192 TTL TLV MUST be used. This will aid the originator of the LSP-Ping 193 echo request in analyzing the return path. 195 4. Operation 197 In this section, we explain a use case for the TTL TLV with an MPLS 198 MS-PW. 199 <------------------MS-PW ---------------------> 201 A B C D E 202 o -------- o -------- o --------- o --------- o 203 ---MPLS Echo Request---> 204 <--MPLS Echo Reply------ 206 Figure 2: Use-case with MS-PWs 208 Let us assume a MS-PW going through LSRs A, B, C, D, and E. 209 Furthermore, assume that an operator wants to perform a connectivity 210 check between B and D from B. Thus, an MPLS Echo Request with the TTL 211 TLV is originated from B and sent towards D. The MPLS Echo Request 212 packet contains the FEC of the PW Segment between C and D. The value 213 field of the TTL TLV and the TTL field of the MPLS label are set to 214 2, the choice of the value 2 will be based on the operator input 215 requesting the MPLS Echo Request or from the optional LDP switching 216 point TLV. The MPLS Echo Request is intercepted at D because of TTL 217 expiry. D detects the TTL TLV in the request, and use the TTL value 218 (i.e., 2) specified in the TLV on the MPLS label of the MPLS Echo 219 Reply. The MPLS Echo Reply will be intercepted by B because of TTL 220 expiry. 222 The same operation will apply in the case a co-routed bidirectional 223 LSP and we want to check connectivity from an intermediate LSR B to 224 another LSR D, from B. 226 4.1. Traceroute mode 228 In the traceroute mode TTL value in the TLV is successively set to 1, 229 2, and so on. This is similar to the TTL values used for the label 230 set on the packet. 232 4.2. Error scenario 234 It is possible that the MPLS Echo Request packet was intercepted 235 before the intended destination for reason other than label TTL 236 expiry. This could be due network faults, misconfiguration or other 237 reasons. In such cases, if the return TTL is set to the value 238 specified in the TTL TLV then the echo response packet will continue 239 beyond the originating node. This becomes a security issue. 241 To prevent this, the label TTL value used in the MPLS Echo Reply 242 packet MUST be modified by deducting the incoming label TTL on the 243 received packet from TTL TLV value. If the MPLS Echo Request packet 244 is punted to the CPU before the incoming label TTL is deducted, then 245 another 1 MUST be deducted. In other words: 247 Return TTL Value on the MPLS Echo Reply packet = (TTL TLV Value)- 248 (Incoming Label TTL) + 1 250 5. Security Considerations 252 This draft allows the setting of the TTL value in the MPLS Label of 253 an MPLS Echo Reply, so that it can be intercepted by an intermediate 254 device. This can cause a device to get a lot of LSP Ping packets 255 which get redirected to the CPU. 257 However the same is possible even without the changes mentioned in 258 this document. A device should rate limit the LSP ping packets 259 redirected to the CPU so that the CPU is not overwhelmed. 261 The recommendation in [RFC4379] security section applies, to check 262 the source address of the MPLS Echo Request, however the source 263 address can now be any node along the LSP path. 265 A faulty transit node changing the TTL TLV value could make the wrong 266 node reply to the MPLS Echo Request, and/or the wrong node to receive 267 the MPLS Echo Reply. An LSP trace may help identify the faulty 268 transit node. 270 6. IANA Considerations 272 IANA is requested to assign TLV type value to the following TLV from 273 the "Multiprotocol Label Switching Architecture (MPLS) Label Switched 274 Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub-TLVs" sub- 275 registry. 277 Time To Live TLV (See Section 3). The value MUST be assigned from the 278 range (32768-49161) of optional TLVs. 280 7. Acknowledgements 282 The authors would like to thank Greg Mirsky for his comments. 284 8. References 286 8.1 Normative References 288 [1] K. Kompella, G. Swallow, "Detecting Multi-Protocol Label Switched 289 (MPLS) Data Plane Failures", RFC 4379, February 2006. 291 [2] T. Nadeau, et. al, "Pseudowire Virtual Circuit Connectivity 292 Verification (VCCV): A Control Channel for Pseudowires ", RFC 5085, 293 December 2007. 295 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 296 Levels", BCP 14, RFC 2119, March 1997. 298 Authors' Addresses 300 Sami Boutros 301 Cisco Systems, Inc. 302 3750 Cisco Way 303 San Jose, California 95134 304 USA 305 Email: sboutros@cisco.com 307 Siva Sivabalan 308 Cisco Systems, Inc. 310 2000 Innovation Drive 311 Kanata, Ontario, K2K 3E8 312 Canada 313 Email: msiva@cisco.com 315 George Swallow 316 Cisco Systems, Inc. 317 300 Beaver Brook Road 318 Boxborough , MASSACHUSETTS 01719 319 United States 320 Email: swallow@cisco.com 322 Shaleen Saxena 323 Cisco Systems, Inc. 324 1414 Massachusetts Avenue 325 Boxborough , MASSACHUSETTS 01719 326 United States 327 Email: ssaxena@cisco.com 329 Vishwas Manral 330 Hewlett Packard Co. 331 19111 Pruneridge Ave, 332 Cupertino, CA 95014 USA 333 United States 334 EMail: vishwas.manral@hp.com 336 Michael Wildt 337 Cisco Systems, Inc. 338 1414 Massachusetts Avenue 339 Boxborough , MASSACHUSETTS 01719 340 United States 341 Email: mwildt@cisco.com 343 Sam Aldrin 344 Huawei Technologies, Inc. 345 1188 Central Express Way, 346 Santa Clara, CA 95051 347 United States 348 Email: aldrin.ietf@gmail.com