idnits 2.17.00 (12 Aug 2021) /tmp/idnits7913/draft-ietf-mpls-ldp-gtsm-05.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 (April 11, 2012) is 3691 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 April 11, 2012 6 Expires: October 13, 2012 8 The Generalized TTL Security Mechanism (GTSM) for Label Distribution 9 Protocol (LDP) 10 draft-ietf-mpls-ldp-gtsm-05 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 Label Distribution 20 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 October 13, 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 LSR neighbors that are not directly connected at the link 84 level. Once discovered, the LSR neighbors can establish the LDP 85 peering session, using the TCP transport connection. 87 The Generalized TTL Security Mechanism (GTSM) [RFC5082] is a 88 mechanism based on IPv4 Time To Live (TTL) or (IPv6) Hop Limit value 89 verification so as to provide a simple and reasonably robust defense 90 from infrastructure attacks using forged protocol packets from 91 outside the network. GTSM can be applied to any protocol peering 92 session that is established between routers that are adjacent. 93 Therefore, GTSM can fully benefit LDP protocol peering session 94 established using Basic Discovery. 96 This document specifies LDP enhancements to accommodate GTSM. In 97 particular, this document specifies the enhancements in the following 98 areas: 100 1. Common Hello Parameter TLV of LDP Link Hello message 102 2. Sending and Receiving procedures for LDP Link Hello message 104 3. Sending and Receiving procedures for LDP Initilization message 106 GTSM specifies that it SHOULD NOT be enabled by default in order to 107 remain backward-compatible with the unmodified protocol; this 108 document specifies having a built-in dynamic GTSM capability 109 negotiation for LDP to suggest the use of GTSM, provided GTSM is not 110 enabled unless both peers can detect each others' support for GTSM 111 procedures and agree on its usage as described in this document. 113 This specification uses a bit reserved in Section 3.5.2 of [RFC5036] 114 and therefore updates [RFC5036]. 116 1.1. Specification of Requirements 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 1.2. Scope 124 This document defines procedures for LDP using IPv4 routing, but not 125 for LDP using IPv6 routing, since the latter has GTSM built into the 126 protocol definition [I-D.ietf-mpls-ldp-ipv6]. 128 Additionally, the GTSM for LDP specified in this document applies 129 only to single-hop LDP peering sessions, and not to multi-hop LDP 130 peering sessions, in line with Section 5.5 of [RFC5082]. 131 Consequently, any LDP method or feature (such as LDP IGP 132 Synchronization [RFC5443], or LDP Session Protection [LDP-SPROT]) 133 that relies on multi-hop LDP peering sessions would not work with 134 GTSM and will require (statically or dynamically) disabling GTSM. 135 See Section 3. 137 2. GTSM Procedures for LDP 139 2.1. GTSM Flag in Common Hello Parameter TLV 141 A new flag in Common Hello Parameter TLV, named G flag (for GTSM), is 142 defined by this document in a previously reserved bit. An LSR 143 indicates that it is capable of applying GTSM procedures, as defined 144 in this document, to the subsequent LDP peering session, by setting 145 the GTSM flag to 1. The Common Hello Parameters TLV, defined in 146 Section 3.5.2 of [RFC5036], is updated as shown in Figure 1. 148 0 1 2 3 149 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 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 |0|0| Common Hello Parms(0x0400)| Length | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Hold Time |T|R|G| Reserved | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 T, Targeted Hello 157 As specified in [RFC5036]. 159 R, Request Send Targeted Hellos 160 As specified in [RFC5036]. 162 G, GTSM 163 A value of 1 specifies that this LSR supports GTSM procedures, 164 where a value of 0 specifies that this LSR does not support GTSM. 166 Reserved 167 This field is reserved. It MUST be set to zero on transmission 168 and ignored on receipt. 170 Figure 1: GTSM Flag in Common Hello Parameter TLV 172 The G flag is meaingful only if T and R flags are set to 0 (which 173 must be the case for Basic Discovery), otherwise, the value of G flag 174 SHOULD be ignored on receipt. 176 Any LSR not supporting GTSM for LDP, as defined in this document, 177 would continue to ignore the G flag, independent of T and R flags' 178 value, as per Section 3.5.2 of [RFC5036]. 180 2.2. GTSM Sending and Receiving Procedures for LDP Link Hello 182 Firstly, LSRs using LDP Basic Discovery [RFC5036] send LDP Hello 183 messages to link-level multicast address (224.0.0.2 or "all 184 routers"). Such messages are never forwarded beyond one hop and 185 assumed to have their IP TTL or Hop Count = 1. 187 An LSR that is capable of applying GTSM procedures to the subsequent 188 TCP/LDP peering session MUST set the G flag (for GTSM) to 1 in Common 189 Hello Parameter TLV in the LDP Link Hello message [RFC5036]. 191 An LSR, upon receiving an LDP Link Hello message, would recognize the 192 presence of G flag (in Common Hello Parameter TLV) only if it 193 supports GTSM for LDP, as specified in this document. If an LSR 194 recognizes the presence of G flag with the value =1 in the received 195 LDP Link Hello message, then it MUST enforce GTSM for LDP in the 196 subsequent TCP/LDP peering session with the neighbor that sent the 197 Hello message, as specified in Section 2.3 of this document. 199 If an LSR does not recognize the presence of G flag (in Common Hello 200 Parameter TLV of Link Hello message), or recognizes the presence of G 201 flag with the value = 0, then the LSR MUST NOT enforce GTSM for LDP 202 in the subsequent TCP/LDP peering session with the neighbor that sent 203 the Hello message. This ensures backward compatibility as well as 204 automatic GTSM de-activation. 206 If an LSR that has sent the LDP Link Hello with G flag = 1, then the 207 LSR MUST set IP TTL or Hop Count = 255 in the forthcoming TCP 208 Transport Connection(s) with that neighbor (e.g., LSR2). Please see 209 Section 2.3 for more details about the TCP transport connection 210 specifics. 212 2.3. GTSM Sending and Receiving Procedures for LDP Initialization 214 If an LSR that has sent and received LDP Link Hello with G flag = 1 215 from the directly-connected neighbor (LSR2), then the LSR MUST 216 enforce GTSM procedures, as defined in Section 3 of [RFC5082], in the 217 forthcoming TCP Transport Connection with that neighbor (LSR2). This 218 means that the LSR MUST check for the incoming unicast packets' TTL 219 or Hop Count to be 255 for the particular LDP/TCP peering session and 220 decide the further processing as per the [RFC5082]. 222 If an LSR that has sent LDP Link Hello with G flag = 1, but received 223 LDP Link Hello with G flag = 0 from the directly-connected neighbor 224 (LSR2), then the LSR MUST NOT enforce GTSM procedures, as defined in 225 Section 3 of [RFC5082], in the forthcoming TCP Transport Connection 226 with that neighbor (LSR2). 228 3. LDP Peering Scenarios and GTSM Considerations 230 This section discusses GTSM considerations arising from the LDP 231 peering scenarios used, including single-hop versus multi-hop LDP 232 neighbors, as well as the use of LDP basic discovery versus extended 233 discovery. 235 The reason GTSM is enabled for Basic Discovery by default, but not 236 for Extended Discovery is that the usage of Basic Discovery typically 237 results in a single-hop LDP peering session, whereas the usage of 238 Extended Discovery typically results in a multi-hop LDP peering 239 session. GTSM protection for multi-hop LDP sessions is outside the 240 scope of this specification (see Section 1.2). However, it is worth 241 clarifying the following exceptions that may occur with Basic or 242 Extended Discovery usage: 244 a. Two adjacent LSRs (i.e., back-to-back PE routers) forming a 245 single-hop LDP peering session after doing an Extended Discovery 246 (e.g., for Pseudowire signaling) 248 b. Two adjacent LSRs forming a multi-hop LDP peering session after 249 doing a Basic Discovery, due to the way IP routing is setup 250 between them (either temporarily or permanently) 252 c. Two adjacent LSRs (i.e. back-to-back PE routers) forming a 253 single-hop LDP peering session after doing both Basic and 254 Extended Discovery. 256 In the first case (a), GTSM is not enabled for the LDP peering 257 session by default. In the second case (b), GTSM is actually enabled 258 by default and enforced for the LDP peering session, and hence, it 259 would prohibit the LDP peering session from getting established (note 260 that this may impact features such as LDP IGP Synchronization 261 [RFC5443], or LDP Session Protection [LDP-SPROT]). en the third case 262 (c), GTSM is enabled by default for Basic Discovery and enforced on 263 the subsequent LDP peering, and not for Extended Discovery. However, 264 if each LSR uses the same IPv4 transport address object value in both 265 Basic and Extended discoveries, then it would result in a single LDP 266 peering session and that would be enabled with GTSM. Otherwise, GTSM 267 would not be enforced on the second LDP peering session corresponding 268 to the Extended Discovery. 270 This document allows for the implementation to provide an option to 271 statically (e.g., via configuration) and/or dynamically override the 272 default behavior and enable/disable GTSM on a per-peer basis. This 273 would address all the exceptions listed above. 275 4. IANA Considerations 277 This document has no IANA actions. 279 5. Security Considerations 281 This document increases the security for LDP, making it more 282 resilient to off-link attacks. 284 6. Acknowledgments 286 The authors of this document do not make any claims on the 287 originality of the ideas described. The concept of GTSM for LDP has 288 been proposed a number of times, and is documented in both the 289 Experimental and Standards Track specifications of GTSM. Among other 290 people, we would like to acknowledge Enke Chen and Albert Tian for 291 their document "TTL-Based Security Option for the LDP Hello Message". 293 The authors would like to thank Loa Andersson, Bin Mo, Mach Chen, 294 Vero Zheng, Adrian Farrel, and Eric Rosen for a thorough review and 295 most useful comments and suggestions. 297 7. References 299 7.1. Normative References 301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 302 Requirement Levels", BCP 14, RFC 2119, March 1997. 304 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 305 Specification", RFC 5036, October 2007. 307 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 308 Pignataro, "The Generalized TTL Security Mechanism 309 (GTSM)", RFC 5082, October 2007. 311 7.2. Informative References 313 [I-D.ietf-mpls-ldp-ipv6] 314 Pignataro, C., Asati, R., Papneja, R., and V. Manral, 315 "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-06 316 (work in progress), January 2012. 318 [LDP-SPROT] 319 Cisco Systems, Inc., "MPLS LDP Session Protection", . 323 [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP 324 Synchronization", RFC 5443, March 2009. 326 Authors' Addresses 328 Carlos Pignataro 329 Cisco Systems 330 7200-12 Kit Creek Road 331 Research Triangle Park, NC 27709 332 US 334 Email: cpignata@cisco.com 336 Rajiv Asati 337 Cisco Systems 338 7025-6 Kit Creek Road 339 Research Triangle Park, NC 27709 340 US 342 Email: rajiva@cisco.com