idnits 2.17.1 draft-ietf-mpls-ldp-gtsm-07.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 29, 2012) is 4321 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: A later version (-17) exists of draft-ietf-mpls-ldp-ipv6-06 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 29, 2012 6 Expires: November 30, 2012 8 The Generalized TTL Security Mechanism (GTSM) for Label Distribution 9 Protocol (LDP) 10 draft-ietf-mpls-ldp-gtsm-07 12 Abstract 14 The Generalized TTL Security Mechanism (GTSM) describes a generalized 15 use of a packet's 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 30, 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 without any 115 configuration. 117 This specification uses a bit reserved in Section 3.5.2 of [RFC5036] 118 and therefore updates [RFC5036]. 120 1.1. Specification of Requirements 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 1.2. Scope 128 This document defines procedures for LDP using IPv4 routing, but not 129 for LDP using IPv6 routing, since the latter has GTSM built into the 130 protocol definition [I-D.ietf-mpls-ldp-ipv6]. 132 Additionally, the GTSM for LDP specified in this document applies 133 only to single-hop LDP peering sessions, and not to multi-hop LDP 134 peering sessions, in line with Section 5.5 of [RFC5082]. 135 Consequently, any LDP method or feature (such as LDP IGP 136 Synchronization [RFC5443], or LDP Session Protection [LDP-SPROT]) 137 that relies on multi-hop LDP peering sessions would not work with 138 GTSM and will require (statically or dynamically) disabling the GTSM 139 capability. See Section 3. 141 2. GTSM Procedures for LDP 143 2.1. GTSM Flag in Common Hello Parameter TLV 145 A new flag in Common Hello Parameter TLV, named G flag (for GTSM), is 146 defined by this document in a previously reserved bit. An LSR 147 indicates that it is capable of applying GTSM procedures, as defined 148 in this document, to the subsequent LDP peering session, by setting 149 the GTSM flag to 1. The Common Hello Parameters TLV, defined in 150 Section 3.5.2 of [RFC5036], is updated as shown in Figure 1. 152 0 1 2 3 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 |0|0| Common Hello Parms(0x0400)| Length | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Hold Time |T|R|G| Reserved | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 T, Targeted Hello 161 As specified in [RFC5036]. 163 R, Request Send Targeted Hellos 164 As specified in [RFC5036]. 166 G, GTSM 167 A value of 1 specifies that this LSR supports GTSM procedures, 168 where a value of 0 specifies that this LSR does not support GTSM. 170 Reserved 171 This field is reserved. It MUST be set to zero on transmission 172 and ignored on receipt. 174 Figure 1: GTSM Flag in Common Hello Parameter TLV 176 The G flag is meaningful only if the T flag is set to 0 (which must 177 be the case for Basic Discovery), otherwise, the value of G flag 178 SHOULD be ignored on receipt. 180 Any LSR not supporting GTSM for LDP as defined in this document 181 (i.e., an LSR that does not recognize the G flag), would continue to 182 ignore the G flag, independent of T and R flags' value, as per 183 Section 3.5.2 of [RFC5036]. Similarly, an LSR that does recognize 184 the G flag but that does not support GTSM (either because it is not 185 implemented, or because it is so configured), would not set the G 186 flag (i.e.,g G=0) when sending LDP Link hellos and would effectively 187 ignore the G flag when receiving LDP Link hello messages. 189 2.2. GTSM Sending and Receiving Procedures for LDP Link Hello 191 Firstly, LSRs using LDP Basic Discovery [RFC5036] send LDP Hello 192 messages to link-level multicast address (224.0.0.2 or "all 193 routers"). Such messages are never forwarded beyond one hop and 194 RECOMMENDED to have their IP TTL or Hop Count = 1. 196 Unless configured otherwise, an LSR that supports GTSM procedures 197 MUST set the G flag (for GTSM) to 1 in Common Hello Parameter TLV in 198 the LDP Link Hello message [RFC5036]. 200 If an LSR that supports GTSM and is configured to use it recognizes 201 the presence of G flag (in Common Hello Parameter TLV) with the value 202 =1 in the received LDP Link Hello message, then it MUST enforce GTSM 203 for LDP in the subsequent TCP/LDP peering session with the neighbor 204 that sent the Hello message, as specified in Section 2.3 of this 205 document. 207 If an LSR does not recognize the presence of G flag (in Common Hello 208 Parameter TLV of Link Hello message), or recognizes the presence of G 209 flag with the value = 0, then the LSR MUST NOT enforce GTSM for LDP 210 in the subsequent TCP/LDP peering session with the neighbor that sent 211 the Hello message. This ensures backward compatibility as well as 212 automatic GTSM de-activation. 214 2.3. GTSM Sending and Receiving Procedures for LDP Initialization 216 If an LSR that has sent and received LDP Link Hello with G flag = 1 217 from the directly-connected neighbor, then the LSR MUST enforce GTSM 218 procedures, as defined in Section 3 of [RFC5082], in the forthcoming 219 TCP Transport Connection with that neighbor. This means that the LSR 220 MUST check for the incoming unicast packets' TTL or Hop Count to be 221 255 for the particular LDP/TCP peering session and decide the further 222 processing as per the [RFC5082]. 224 If an LSR that has sent LDP Link Hello with G flag = 1, but received 225 LDP Link Hello with G flag = 0 from the directly-connected neighbor, 226 then the LSR MUST NOT enforce GTSM procedures, as defined in Section 227 3 of [RFC5082], in the forthcoming TCP Transport Connection with that 228 neighbor. 230 3. LDP Peering Scenarios and GTSM Considerations 232 This section discusses GTSM considerations arising from the LDP 233 peering scenarios used, including single-hop versus multi-hop LDP 234 neighbors, as well as the use of LDP basic discovery versus extended 235 discovery. 237 The reason that the GTSM capability negotiation is enabled for Basic 238 Discovery by default (i.e.,g G=1), but not for Extended Discovery is 239 that the usage of Basic Discovery typically results in a single-hop 240 LDP peering session, whereas the usage of Extended Discovery 241 typically results in a multi-hop LDP peering session. GTSM 242 protection for multi-hop LDP sessions is outside the scope of this 243 specification (see Section 1.2). However, it is worth clarifying the 244 following exceptions that may occur with Basic or Extended Discovery 245 usage: 247 a. Two adjacent LSRs (i.e., back-to-back PE routers) forming a 248 single-hop LDP peering session after doing an Extended Discovery 249 (e.g., for Pseudowire signaling) 251 b. Two adjacent LSRs forming a multi-hop LDP peering session after 252 doing a Basic Discovery, due to the way IP routing is setup 253 between them (either temporarily or permanently) 255 c. Two adjacent LSRs (i.e. back-to-back PE routers) forming a 256 single-hop LDP peering session after doing both Basic and 257 Extended Discovery. 259 In the first case (a), GTSM is not enabled for the LDP peering 260 session by default. In the second case (b), GTSM is actually enabled 261 by default and enforced for the LDP peering session, and hence, it 262 would prohibit the LDP peering session from getting established (note 263 that this may impact features such as LDP IGP Synchronization 264 [RFC5443], or LDP Session Protection [LDP-SPROT]). In the third case 265 (c), GTSM is enabled by default for Basic Discovery and enforced on 266 the subsequent LDP peering, and not for Extended Discovery. However, 267 if each LSR uses the same IPv4 transport address object value in both 268 Basic and Extended discoveries, then it would result in a single LDP 269 peering session and that would be enabled with GTSM. Otherwise, GTSM 270 would not be enforced on the second LDP peering session corresponding 271 to the Extended Discovery. 273 This document allows for the implementation to provide an option to 274 statically (e.g., via configuration) and/or dynamically override the 275 default behavior and enable/disable GTSM on a per-peer basis. This 276 would address all the exceptions listed above. 278 4. IANA Considerations 280 This document has no IANA actions. 282 5. Security Considerations 284 This document increases the security for LDP, making it more 285 resilient to off-link attacks. Security considerations for GTSM are 286 detailed in Section 5 of [RFC5082]. 288 6. Acknowledgments 290 The authors of this document do not make any claims on the 291 originality of the ideas described. The concept of GTSM for LDP has 292 been proposed a number of times, and is documented in both the 293 Experimental and Standards Track specifications of GTSM. Among other 294 people, we would like to acknowledge Enke Chen and Albert Tian for 295 their document "TTL-Based Security Option for the LDP Hello Message". 297 The authors would like to thank Loa Andersson, Bin Mo, Mach Chen, 298 Vero Zheng, Adrian Farrel, Eric Rosen, and Eric Gray for a thorough 299 review and most useful comments and suggestions. 301 7. References 303 7.1. Normative References 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", BCP 14, RFC 2119, March 1997. 308 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 309 Specification", RFC 5036, October 2007. 311 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 312 Pignataro, "The Generalized TTL Security Mechanism 313 (GTSM)", RFC 5082, October 2007. 315 7.2. Informative References 317 [I-D.ietf-mpls-ldp-ipv6] 318 Pignataro, C., Asati, R., Papneja, R., and V. Manral, 319 "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-06 320 (work in progress), January 2012. 322 [LDP-SPROT] 323 Cisco Systems, Inc., "MPLS LDP Session Protection", . 327 [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP 328 Synchronization", RFC 5443, March 2009. 330 Authors' Addresses 332 Carlos Pignataro 333 Cisco Systems 334 7200-12 Kit Creek Road 335 Research Triangle Park, NC 27709 336 US 338 Email: cpignata@cisco.com 340 Rajiv Asati 341 Cisco Systems 342 7025-6 Kit Creek Road 343 Research Triangle Park, NC 27709 344 US 346 Email: rajiva@cisco.com