idnits 2.17.00 (12 Aug 2021) /tmp/idnits8624/draft-ietf-mpls-ldp-gtsm-06.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 (Using the creation date from RFC5036, updated by this document, for RFC5378 checks: 2004-10-12) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 14, 2012) is 3658 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) == Outdated reference: draft-ietf-mpls-ldp-ipv6 has been published as RFC 7552 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group C. Pignataro 3 Internet-Draft R. Asati 4 Updates: 5036 (if approved) Cisco Systems 5 Intended status: Standards Track May 14, 2012 6 Expires: November 15, 2012 8 The Generalized TTL Security Mechanism (GTSM) for Label Distribution 9 Protocol (LDP) 10 draft-ietf-mpls-ldp-gtsm-06 12 Abstract 14 The Generalized TTL Security Mechanism (GTSM) describes a generalized 15 use of a packets Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to 16 verify that the packet was sourced by a node on a connected link, 17 thereby protecting the router's IP control-plane from CPU utilization 18 based attacks. This technique improves security and is used by many 19 protocols. This document defines the GTSM use for the Label 20 Distribution Protocol (LDP). 22 This specification uses a bit reserved in RFC 5036 and therefore 23 updates RFC 5036. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 15, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Specification of Requirements . . . . . . . . . . . . . . . 3 61 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. GTSM Procedures for LDP . . . . . . . . . . . . . . . . . . . . 4 63 2.1. GTSM Flag in Common Hello Parameter TLV . . . . . . . . . . 4 64 2.2. GTSM Sending and Receiving Procedures for LDP Link 65 Hello . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.3. GTSM Sending and Receiving Procedures for LDP 67 Initialization . . . . . . . . . . . . . . . . . . . . . . 6 68 3. LDP Peering Scenarios and GTSM Considerations . . . . . . . . . 6 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 71 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 74 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 LDP [RFC5036] specifies two peer discovery mechanisms, a Basic one 80 and an Extended one, both using UDP transport. The Basic Discovery 81 mechanism is used to discover LDP peers that are directly connected 82 at the link level, whereas the Extended Discovery mechanism is used 83 to locate Label Switching Router (LSR) neighbors that are not 84 directly connected at the link level. Once discovered, the LSR 85 neighbors can establish the LDP peering session, using the TCP 86 transport connection. 88 The Generalized TTL Security Mechanism (GTSM) [RFC5082] is a 89 mechanism based on IPv4 Time To Live (TTL) or (IPv6) Hop Limit value 90 verification so as to provide a simple and reasonably robust defense 91 from infrastructure attacks using forged protocol packets from 92 outside the network. GTSM can be applied to any protocol peering 93 session that is established between routers that are adjacent. 94 Therefore, GTSM can fully benefit LDP protocol peering session 95 established using Basic Discovery. 97 This document specifies LDP enhancements to accommodate GTSM. In 98 particular, this document specifies the enhancements in the following 99 areas: 101 1. Common Hello Parameter TLV of LDP Link Hello message 103 2. Sending and Receiving procedures for LDP Link Hello message 105 3. Sending and Receiving procedures for LDP Initilization message 107 GTSM specifies that "it SHOULD NOT be enabled by default in order to 108 remain backward-compatible with the unmodified protocol" (see Section 109 3 of [RFC5082]). This document specifies a "built-in dynamic GTSM 110 capability negotiation" for LDP to suggest the use of GTSM. GTSM 111 will be used as specified in this document provided both peers on an 112 LDP session can detect each others' support for GTSM procedures and 113 agree to use it. That is, the desire to use GTSM (i.e., its 114 negotiation mechanics) is enabled by default. 116 This specification uses a bit reserved in Section 3.5.2 of [RFC5036] 117 and therefore updates [RFC5036]. 119 1.1. Specification of Requirements 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 1.2. Scope 127 This document defines procedures for LDP using IPv4 routing, but not 128 for LDP using IPv6 routing, since the latter has GTSM built into the 129 protocol definition [I-D.ietf-mpls-ldp-ipv6]. 131 Additionally, the GTSM for LDP specified in this document applies 132 only to single-hop LDP peering sessions, and not to multi-hop LDP 133 peering sessions, in line with Section 5.5 of [RFC5082]. 134 Consequently, any LDP method or feature (such as LDP IGP 135 Synchronization [RFC5443], or LDP Session Protection [LDP-SPROT]) 136 that relies on multi-hop LDP peering sessions would not work with 137 GTSM and will require (statically or dynamically) disabling the GTSM 138 capability. See Section 3. 140 2. GTSM Procedures for LDP 142 2.1. GTSM Flag in Common Hello Parameter TLV 144 A new flag in Common Hello Parameter TLV, named G flag (for GTSM), is 145 defined by this document in a previously reserved bit. An LSR 146 indicates that it is capable of applying GTSM procedures, as defined 147 in this document, to the subsequent LDP peering session, by setting 148 the GTSM flag to 1. The Common Hello Parameters TLV, defined in 149 Section 3.5.2 of [RFC5036], is updated as shown in Figure 1. 151 0 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 |0|0| Common Hello Parms(0x0400)| Length | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Hold Time |T|R|G| Reserved | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 T, Targeted Hello 160 As specified in [RFC5036]. 162 R, Request Send Targeted Hellos 163 As specified in [RFC5036]. 165 G, GTSM 166 A value of 1 specifies that this LSR supports GTSM procedures, 167 where a value of 0 specifies that this LSR does not support GTSM. 169 Reserved 170 This field is reserved. It MUST be set to zero on transmission 171 and ignored on receipt. 173 Figure 1: GTSM Flag in Common Hello Parameter TLV 175 The G flag is meaingful only if the T flag is set to 0 (which must be 176 the case for Basic Discovery), otherwise, the value of G flag SHOULD 177 be ignored on receipt. 179 Any LSR not supporting GTSM for LDP as defined in this document 180 (i.e., an LSR that does not recognize the G flag), would continue to 181 ignore the G flag, independent of T and R flags' value, as per 182 Section 3.5.2 of [RFC5036]. Similarly, an LSR that does recognize 183 the G flag but that it does not support GTSM (either because it is 184 not implemented, or because it is so configured), would clear the G 185 flag (i.e.,g G=0) on send and would effectively ignore the G flag on 186 receipt. 188 2.2. GTSM Sending and Receiving Procedures for LDP Link Hello 190 Firstly, LSRs using LDP Basic Discovery [RFC5036] send LDP Hello 191 messages to link-level multicast address (224.0.0.2 or "all 192 routers"). Such messages are never forwarded beyond one hop and 193 RECOMMENDED to have their IP TTL or Hop Count = 1. 195 Unless configured otherwise, an LSR that supports GTSM procedures 196 MUST set the G flag (for GTSM) to 1 in Common Hello Parameter TLV in 197 the LDP Link Hello message [RFC5036]. 199 If an LSR that supports GTSM and is configured to use it recognizes 200 the presence of G flag (in Common Hello Parameter TLV) with the value 201 =1 in the received LDP Link Hello message, then it MUST enforce GTSM 202 for LDP in the subsequent TCP/LDP peering session with the neighbor 203 that sent the Hello message, as specified in Section 2.3 of this 204 document. 206 If an LSR does not recognize the presence of G flag (in Common Hello 207 Parameter TLV of Link Hello message), or recognizes the presence of G 208 flag with the value = 0, then the LSR MUST NOT enforce GTSM for LDP 209 in the subsequent TCP/LDP peering session with the neighbor that sent 210 the Hello message. This ensures backward compatibility as well as 211 automatic GTSM de-activation. 213 2.3. GTSM Sending and Receiving Procedures for LDP Initialization 215 If an LSR that has sent and received LDP Link Hello with G flag = 1 216 from the directly-connected neighbor, then the LSR MUST enforce GTSM 217 procedures, as defined in Section 3 of [RFC5082], in the forthcoming 218 TCP Transport Connection with that neighbor. This means that the LSR 219 MUST check for the incoming unicast packets' TTL or Hop Count to be 220 255 for the particular LDP/TCP peering session and decide the further 221 processing as per the [RFC5082]. 223 If an LSR that has sent LDP Link Hello with G flag = 1, but received 224 LDP Link Hello with G flag = 0 from the directly-connected neighbor, 225 then the LSR MUST NOT enforce GTSM procedures, as defined in Section 226 3 of [RFC5082], in the forthcoming TCP Transport Connection with that 227 neighbor. 229 3. LDP Peering Scenarios and GTSM Considerations 231 This section discusses GTSM considerations arising from the LDP 232 peering scenarios used, including single-hop versus multi-hop LDP 233 neighbors, as well as the use of LDP basic discovery versus extended 234 discovery. 236 The reason that the GTSM capability negotiation is enabled for Basic 237 Discovery by default (i.e.,g G=1), but not for Extended Discovery is 238 that the usage of Basic Discovery typically results in a single-hop 239 LDP peering session, whereas the usage of Extended Discovery 240 typically results in a multi-hop LDP peering session. GTSM 241 protection for multi-hop LDP sessions is outside the scope of this 242 specification (see Section 1.2). However, it is worth clarifying the 243 following exceptions that may occur with Basic or Extended Discovery 244 usage: 246 a. Two adjacent LSRs (i.e., back-to-back PE routers) forming a 247 single-hop LDP peering session after doing an Extended Discovery 248 (e.g., for Pseudowire signaling) 250 b. Two adjacent LSRs forming a multi-hop LDP peering session after 251 doing a Basic Discovery, due to the way IP routing is setup 252 between them (either temporarily or permanently) 254 c. Two adjacent LSRs (i.e. back-to-back PE routers) forming a 255 single-hop LDP peering session after doing both Basic and 256 Extended Discovery. 258 In the first case (a), GTSM is not enabled for the LDP peering 259 session by default. In the second case (b), GTSM is actually enabled 260 by default and enforced for the LDP peering session, and hence, it 261 would prohibit the LDP peering session from getting established (note 262 that this may impact features such as LDP IGP Synchronization 263 [RFC5443], or LDP Session Protection [LDP-SPROT]). In the third case 264 (c), GTSM is enabled by default for Basic Discovery and enforced on 265 the subsequent LDP peering, and not for Extended Discovery. However, 266 if each LSR uses the same IPv4 transport address object value in both 267 Basic and Extended discoveries, then it would result in a single LDP 268 peering session and that would be enabled with GTSM. Otherwise, GTSM 269 would not be enforced on the second LDP peering session corresponding 270 to the Extended Discovery. 272 This document allows for the implementation to provide an option to 273 statically (e.g., via configuration) and/or dynamically override the 274 default behavior and enable/disable GTSM on a per-peer basis. This 275 would address all the exceptions listed above. 277 4. IANA Considerations 279 This document has no IANA actions. 281 5. Security Considerations 283 This document increases the security for LDP, making it more 284 resilient to off-link attacks. Security considerations for GTSM are 285 detailed in Section 5 of [RFC5082]. 287 6. Acknowledgments 289 The authors of this document do not make any claims on the 290 originality of the ideas described. The concept of GTSM for LDP has 291 been proposed a number of times, and is documented in both the 292 Experimental and Standards Track specifications of GTSM. Among other 293 people, we would like to acknowledge Enke Chen and Albert Tian for 294 their document "TTL-Based Security Option for the LDP Hello Message". 296 The authors would like to thank Loa Andersson, Bin Mo, Mach Chen, 297 Vero Zheng, Adrian Farrel, and Eric Rosen for a thorough review and 298 most useful comments and suggestions. 300 7. References 302 7.1. Normative References 304 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 305 Requirement Levels", BCP 14, RFC 2119, March 1997. 307 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 308 Specification", RFC 5036, October 2007. 310 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 311 Pignataro, "The Generalized TTL Security Mechanism 312 (GTSM)", RFC 5082, October 2007. 314 7.2. Informative References 316 [I-D.ietf-mpls-ldp-ipv6] 317 Pignataro, C., Asati, R., Papneja, R., and V. Manral, 318 "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-06 319 (work in progress), January 2012. 321 [LDP-SPROT] 322 Cisco Systems, Inc., "MPLS LDP Session Protection", . 326 [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP 327 Synchronization", RFC 5443, March 2009. 329 Authors' Addresses 331 Carlos Pignataro 332 Cisco Systems 333 7200-12 Kit Creek Road 334 Research Triangle Park, NC 27709 335 US 337 Email: cpignata@cisco.com 339 Rajiv Asati 340 Cisco Systems 341 7025-6 Kit Creek Road 342 Research Triangle Park, NC 27709 343 US 345 Email: rajiva@cisco.com