idnits 2.17.1 draft-ietf-mpls-ldp-gtsm-04.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 (November 13, 2011) is 4519 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-05 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 November 13, 2011 6 Expires: May 16, 2012 8 The Generalized TTL Security Mechanism (GTSM) for Label Distribution 9 Protocol (LDP) 10 draft-ietf-mpls-ldp-gtsm-04 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 May 16, 2012. 42 Copyright Notice 44 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 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 that relies on multi-hop LDP 132 peering sessions would not work with GTSM and will require 133 (statically or dynamically) disabling GTSM. See Section 3. 135 2. GTSM Procedures for LDP 137 2.1. GTSM Flag in Common Hello Parameter TLV 139 A new flag in Common Hello Parameter TLV, named G flag (for GTSM), is 140 defined by this document in a previously reserved bit. An LSR 141 indicates that it is capable of applying GTSM procedures, as defined 142 in this document, to the subsequent LDP peering session, by setting 143 the GTSM flag to 1. The Common Hello Parameters TLV, defined in 144 Section 3.5.2 of [RFC5036], is updated as shown in Figure 1. 146 0 1 2 3 147 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 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 |0|0| Common Hello Parms(0x0400)| Length | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Hold Time |T|R|G| Reserved | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 T, Targeted Hello 155 As specified in [RFC5036]. 157 R, Request Send Targeted Hellos 158 As specified in [RFC5036]. 160 G, GTSM 161 A value of 1 specifies that this LSR supports GTSM procedures, 162 where a value of 0 specifies that this LSR does not support GTSM. 164 Reserved 165 This field is reserved. It MUST be set to zero on transmission 166 and ignored on receipt. 168 Figure 1: GTSM Flag in Common Hello Parameter TLV 170 The G flag is meaingful only if T and R flags are set to 0 (which 171 must be the case for Basic Discovery), otherwise, the value of G flag 172 SHOULD be ignored on receipt. 174 Any LSR not supporting GTSM for LDP, as defined in this document, 175 would continue to ignore the G flag, independent of T and R flags' 176 value, as per Section 3.5.2 of [RFC5036]. 178 2.2. GTSM Sending and Receiving Procedures for LDP Link Hello 180 Firstly, LSRs using LDP Basic Discovery [RFC5036] send LDP Hello 181 messages to link-level multicast address (224.0.0.2 or "all 182 routers"). Such messages are never forwarded beyond one hop and 183 assumed to have their IP TTL or Hop Count = 1. 185 An LSR that is capable of applying GTSM procedures to the subsequent 186 TCP/LDP peering session MUST set the G flag (for GTSM) to 1 in Common 187 Hello Parameter TLV in the LDP Link Hello message [RFC5036]. 189 An LSR, upon receiving an LDP Link Hello message, would recognize the 190 presence of G flag (in Common Hello Parameter TLV) only if it 191 supports GTSM for LDP, as specified in this document. If an LSR 192 recognizes the presence of G flag with the value =1 in the received 193 LDP Link Hello message, then it MUST enforce GTSM for LDP in the 194 subsequent TCP/LDP peering session with the neighbor that sent the 195 Hello message, as specified in Section 2.3 of this document. 197 If an LSR does not recognize the presence of G flag (in Common Hello 198 Parameter TLV of Link Hello message), or recognizes the presence of G 199 flag with the value = 0, then the LSR MUST NOT enforce GTSM for LDP 200 in the subsequent TCP/LDP peering session with the neighbor that sent 201 the Hello message. This ensures backward compatibility as well as 202 automatic GTSM de-activation. 204 If an LSR that has sent the LDP Link Hello with G flag = 1, then the 205 LSR MUST set IP TTL or Hop Count = 255 in the forthcoming TCP 206 Transport Connection(s) with that neighbor (e.g., LSR2). Please see 207 Section 2.3 for more details about the TCP transport connection 208 specifics. 210 2.3. GTSM Sending and Receiving Procedures for LDP Initialization 212 If an LSR that has sent and received LDP Link Hello with G flag = 1 213 from the directly-connected neighbor (LSR2), then the LSR MUST 214 enforce GTSM procedures, as defined in Section 3 of [RFC5082], in the 215 forthcoming TCP Transport Connection with that neighbor (LSR2). This 216 means that the LSR MUST check for the incoming unicast packets' TTL 217 or Hop Count to be 255 for the particular LDP/TCP peering session and 218 decide the further processing as per the [RFC5082]. 220 If an LSR that has sent LDP Link Hello with G flag = 1, but received 221 LDP Link Hello with G flag = 0 from the directly-connected neighbor 222 (LSR2), then the LSR MUST NOT enforce GTSM procedures, as defined in 223 Section 3 of [RFC5082], in the forthcoming TCP Transport Connection 224 with that neighbor (LSR2). 226 3. LDP Peering Scenarios and GTSM Considerations 228 This section discusses GTSM considerations arising from the LDP 229 peering scenarios used, including single-hop versus multi-hop LDP 230 neighbors, as well as the use of LDP basic discovery versus extended 231 discovery. 233 The reason GTSM is enabled for Basic Discovery by default, but not 234 for Extended Discovery is that the usage of Basic Discovery typically 235 results in a single-hop LDP peering session, whereas the usage of 236 Extended Discovery typically results in a multi-hop LDP peering 237 session. GTSM protection for multi-hop LDP sessions is outside the 238 scope of this specification (see Section 1.2). However, it is worth 239 clarifying the following exceptions that may occur with Basic or 240 Extended Discovery usage: 242 a. Two adjacent LSRs (i.e., back-to-back PE routers) forming a 243 single-hop LDP peering session after doing an Extended Discovery 244 (e.g., for Pseudowire signaling) 246 b. Two adjacent LSRs forming a multi-hop LDP peering session after 247 doing a Basic Discovery, due to the way IP routing is setup 248 between them (either temporarily or permanently) 250 c. Two adjacent LSRs (i.e. back-to-back PE routers) forming a 251 single-hop LDP peering session after doing both Basic and 252 Extended Discovery. 254 In the first case (a), GTSM is not enabled for the LDP peering 255 session by default. In the second case (b), GTSM is actually enabled 256 by default and enforced for the LDP peering session, and hence, it 257 would prohibit the LDP peering session from getting established. In 258 the third case (c), GTSM is enabled by default for Basic Discovery 259 and enforced on the subsequent LDP peering, and not for Extended 260 Discovery. However, if each LSR uses the same IPv4 transport address 261 object value in both Basic and Extended discoveries, then it would 262 result in a single LDP peering session and that would be enabled with 263 GTSM. Otherwise, GTSM would not be enforced on the second LDP 264 peering session corresponding to the Extended Discovery. 266 This document allows for the implementation to provide an option to 267 statically (e.g., via configuration) and/or dynamically override the 268 default behavior and enable/disable GTSM on a per-peer basis. This 269 would address all the exceptions listed above. 271 4. IANA Considerations 273 This document has no IANA actions. 275 5. Security Considerations 277 This document increases the security for LDP, making it more 278 resilient to off-link attacks. 280 6. Acknowledgments 282 The authors of this document do not make any claims on the 283 originality of the ideas described. The concept of GTSM for LDP has 284 been proposed a number of times, and is documented in both the 285 Experimental and Standards Track specifications of GTSM. Among other 286 people, we would like to acknowledge Enke Chen and Albert Tian for 287 their document "TTL-Based Security Option for the LDP Hello Message". 289 The authors would like to thank Loa Andersson, Bin Mo, Mach Chen, 290 Vero Zheng, Adrian Farrel, and Eric Rosen for a thorough review and 291 most useful comments and suggestions. 293 7. References 295 7.1. Normative References 297 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 298 Requirement Levels", BCP 14, RFC 2119, March 1997. 300 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 301 Specification", RFC 5036, October 2007. 303 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 304 Pignataro, "The Generalized TTL Security Mechanism 305 (GTSM)", RFC 5082, October 2007. 307 7.2. Informative References 309 [I-D.ietf-mpls-ldp-ipv6] 310 Asati, R., Manral, V., Papneja, R., and C. Pignataro, 311 "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-05 312 (work in progress), August 2011. 314 Authors' Addresses 316 Carlos Pignataro 317 Cisco Systems 318 7200-12 Kit Creek Road 319 Research Triangle Park, NC 27709 320 US 322 Email: cpignata@cisco.com 324 Rajiv Asati 325 Cisco Systems 326 7025-6 Kit Creek Road 327 Research Triangle Park, NC 27709 328 US 330 Email: rajiva@cisco.com