idnits 2.17.1 draft-ietf-mpls-ldp-gtsm-02.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 (August 22, 2011) is 4602 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-04 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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 Intended status: Standards Track Cisco Systems 5 Expires: February 23, 2012 August 22, 2011 7 The Generalized TTL Security Mechanism (GTSM) for Label Distribution 8 Protocol (LDP) 9 draft-ietf-mpls-ldp-gtsm-02 11 Abstract 13 The Generalized TTL Security Mechanism (GTSM) describes a generalized 14 use of a packets Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to 15 verify that the packet was sourced by a node on a connected link, 16 thereby protecting the router's IP control-plane from CPU utilization 17 based attacks. This technique improves security and is used by many 18 protocols. This document defines the GTSM use for Label Distribution 19 Protocol (LDP). 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 23, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Specification of Requirements . . . . . . . . . . . . . . . 3 57 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. GTSM Procedures for LDP . . . . . . . . . . . . . . . . . . . . 4 59 2.1. GTSM Flag in Common Hello Parameter TLV . . . . . . . . . . 4 60 2.2. GTSM Sending and Receiving Procedures for LDP Link 61 Hello . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.3. GTSM Sending and Receiving Procedures for LDP 63 Initialization . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Multi-Hop LDP peering Considerations for GTSM . . . . . . . . . 6 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 67 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 70 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 LDP [RFC5036] specifies two peer discovery mechanisms, a Basic one 76 and an Extended one, both using UDP transport. The Basic Discovery 77 mechanism is used to discover LDP peers that are directly connected 78 at the link level, whereas the Extended Discovery mechanism is used 79 to locate LSR neighbors that are not directly connected at the link 80 level. Once discovered, the LSR neighbors can establish the LDP 81 peering session, using the TCP transport connection. 83 The Generalized TTL Security Mechanism (GTSM) [RFC5082] is a 84 mechanism based on IPv4 Time To Live (TTL) or (IPv6) Hop Limit value 85 verification so as to provide a simple and reasonably robust defense 86 from infrastructure attacks using forged protocol packets from 87 outside the network. GTSM can be applied to any protocol peering 88 session that is established between routers that are adjacent. 89 Therefore, GTSM can fully benefit LDP protocol peering session 90 established using Basic Discovery. 92 This document specifies LDP enhancements to accommodate GTSM. In 93 particular, this document specifies the enhancements in the following 94 areas: 96 1. Common Hello Parameter TLV of LDP Link Hello message 98 2. Sending and Receiving procedures for LDP Link Hello message 100 3. Sending and Receiving procedures for LDP Initilization message 102 GTSM specifies that it SHOULD NOT be enabled by default in order to 103 remain backward-compatible with the unmodified protocol; this 104 document specifies having a built-in dynamic GTSM capability 105 negotiation for LDP to suggest the use of GTSM, provided GTSM is not 106 enabled unless both peers can detect each others' support for GTSM 107 procedures and agree on its usage as described in this document. 109 1.1. Specification of Requirements 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 1.2. Scope 117 This document defines procedures for LDP using IPv4 routing, but not 118 for LDP using IPv6 routing, since the latter has GTSM built into the 119 protocol definition [I-D.ietf-mpls-ldp-ipv6]. 121 Additionally, the GTSM for LDP specified in this document applies 122 only to single-hop LDP peering sessions, and not to multi-hop LDP 123 peering sessions, in line with Section 5.5 of [RFC5082]. 124 Consequently, any LDP method or feature that relies on multi-hop LDP 125 peering sessions would not work with GTSM and will require 126 (statically or dynamically) disabling GTSM. See Section 3. 128 2. GTSM Procedures for LDP 130 2.1. GTSM Flag in Common Hello Parameter TLV 132 A new flag in Common Hello Parameter TLV, named G flag (for GTSM), is 133 defined by this document. An LSR indicates that it is capable of 134 applying GTSM procedures, as defined in this document, to the 135 subsequent LDP peering session, by setting the GTSM flag to 1. The 136 Common Hello Parameters TLV, defined in Section 3.5.2 of [RFC5036], 137 is updated as shown in Figure 1. 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 |0|0| Common Hello Parms(0x0400)| Length | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Hold Time |T|R|G| Reserved | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 T, Targeted Hello 148 As specified in [RFC5036]. 150 R, Request Send Targeted Hellos 151 As specified in [RFC5036]. 153 G, GTSM 154 A value of 1 specifies that this LSR supports GTSM procedures, 155 where a value of 0 specifies that this LSR does not support GTSM. 157 Reserved 158 This field is reserved. It MUST be set to zero on transmission 159 and ignored on receipt. 161 Figure 1: GTSM Flag in Common Hello Parameter TLV 163 The G flag is meaingful only if T and R flags are set to 0 (which 164 must be the case for Basic Discovery), otherwise, the value of G flag 165 SHOULD be ignored on receipt. 167 Any LSR not supporting GTSM for LDP, as defined in this document, 168 would continue to ignore the G flag, independent of T and R flags' 169 value, as per Section 3.5.2 of [RFC5036]. 171 2.2. GTSM Sending and Receiving Procedures for LDP Link Hello 173 Firstly, LSRs using LDP Basic Discovery [RFC5036] send LDP Hello 174 messages to link-level multicast address (224.0.0.2 or "all 175 routers"). Such messages are never forwarded beyond one hop and 176 assumed to have their IP TTL or Hop Count = 1. 178 An LSR that is capable of applying GTSM procedures to the subsequent 179 TCP/LDP peering session MUST set the G flag (for GTSM) to 1 in Common 180 Hello Parameter TLV in the LDP Link Hello message [RFC5036]. 182 An LSR, upon receiving an LDP Link Hello message, would recognize the 183 presence of G flag (in Common Hello Parameter TLV) only if it 184 supports GTSM for LDP, as specified in this document. If an LSR 185 recognizes the presence of G flag with the value =1 in the received 186 LDP Link Hello message, then it MUST enforce GTSM for LDP in the 187 subsequent TCP/LDP peering session with the neighbor that sent the 188 Hello message, as specified in Section 2.3 of this document. 190 If an LSR does not recognize the presence of G flag (in Common Hello 191 Parameter TLV of Link Hello message), or recognizes the presence of G 192 flag with the value = 0, then the LSR MUST NOT enforce GTSM for LDP 193 in the subsequent TCP/LDP peering session with the neighbor that sent 194 the Hello message. This ensures backward compatibility as well as 195 automatic GTSM de-activation. 197 If an LSR that has sent the LDP Link Hello with G flag = 1, then the 198 LSR MUST set IP TTL or Hop Count = 255 in the forthcoming TCP 199 Transport Connection(s) with that neighbor (e.g., LSR2). Please see 200 Section 2.3 for more details about the TCP transport connection 201 specifics. 203 2.3. GTSM Sending and Receiving Procedures for LDP Initialization 205 If an LSR that has sent and received LDP Link Hello with G flag = 1 206 from the directly-connected neighbor (LSR2), then the LSR MUST 207 enforce GTSM procedures, as defined in Section 3 of [RFC5082], in the 208 forthcoming TCP Transport Connection with that neighbor (LSR2). This 209 means that the LSR MUST check for the incoming unicast packets' TTL 210 or Hop Count to be 255 for the particular LDP/TCP peering session and 211 decide the further processing as per the [RFC5082]. 213 If an LSR that has sent LDP Link Hello with G flag = 1, but received 214 LDP Link Hello with G flag = 0 from the directly-connected neighbor 215 (LSR2), then the LSR MUST NOT enforce GTSM procedures, as defined in 216 Section 3 of [RFC5082], in the forthcoming TCP Transport Connection 217 with that neighbor (LSR2). 219 3. Multi-Hop LDP peering Considerations for GTSM 221 The reason GTSM is enabled for Basic Discovery by default, but not 222 for Extended Discovery is that the usage of Basic Discovery typically 223 results in a single-hop LDP peering session, whereas the usage of 224 Extended Discovery typically results in a multi-hop LDP peering 225 session. GTSM protection for multi-hop LDP sessions is outside the 226 scope of this specification (see Section 1.2). However, it is worth 227 clarifying the following exceptions that may occur with Basic or 228 Extended Discovery usage: 230 a. Two adjacent LSRs (i.e., back-to-back PE routers) forming a 231 single-hop LDP peering session after doing an Extended Discovery 232 (e.g., for Pseudowire signaling) 234 b. Two adjacent LSRs forming a multi-hop LDP peering session after 235 doing a Basic Discovery, due to the way IP routing is setup 236 between them (either temporarily or permanently) 238 c. Two adjacent LSRs (i.e. back-to-back PE routers) forming a 239 single-hop LDP peering session after doing both Basic and 240 Extended Discovery. 242 In the first case (a), GTSM is not enabled for the LDP peering 243 session by default. In the second case (b), GTSM is actually enabled 244 by default and enforced for the LDP peering session, and hence, it 245 would prohibit the LDP peering session from getting established. In 246 the third case (c), GTSM is enabled by default for Basic Discovery 247 and enforced on the subsequent LDP peering, and not for Extended 248 Discovery. However, if each LSR uses the same IPv4 transport address 249 object value in both Basic and Extended discoveries, then it would 250 result in a single LDP peering session and that would be enabled with 251 GTSM. Otherwise, GTSM would not be enforced on the second LDP 252 peering session corresponding to the Extended Discovery. 254 This document allows for the implementation to provide an option to 255 statically (e.g., via configuration) and/or dynamically override the 256 default behavior and disable GTSM on a per-peer basis. This would 257 address all the exceptions listed above. 259 4. IANA Considerations 261 IANA is requested to assign the G, GTSM bit in the Common Hello 262 Parameters TLV (see Figure 1 in Section 2.1), as per allocation 263 policy defined at [I-D.ietf-mpls-ldp-iana]. 265 5. Security Considerations 267 This document increases the security for LDP, making it more 268 resilient to off-link attacks. 270 6. Acknowledgments 272 The authors of this document do not make any claims on the 273 originality of the ideas described. The concept of GTSM for LDP has 274 been proposed a number of times, and is documented in both the 275 Experimental and Standards Track specifications of GTSM. Among other 276 people, we would like to acknowledge Enke Chen and Albert Tian for 277 their document "TTL-Based Security Option for the LDP Hello Message". 279 The authors would like to thank Loa Andersson and Bin Mo for a 280 thorough review and most useful comments and suggestions. 282 7. References 284 7.1. Normative References 286 [I-D.ietf-mpls-ldp-iana] 287 Pignataro, C. and R. Asati, "Label Distribution Protocol 288 (LDP) Internet Assigned Numbers Authority (IANA) 289 Considerations Update", draft-ietf-mpls-ldp-iana-01 (work 290 in progress), May 2011. 292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, RFC 2119, March 1997. 295 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 296 Specification", RFC 5036, October 2007. 298 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 299 Pignataro, "The Generalized TTL Security Mechanism 300 (GTSM)", RFC 5082, October 2007. 302 7.2. Informative References 304 [I-D.ietf-mpls-ldp-ipv6] 305 Manral, V., Papneja, R., Asati, R., and C. Pignataro, 306 "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-04 307 (work in progress), May 2011. 309 Authors' Addresses 311 Carlos Pignataro 312 Cisco Systems 313 7200-12 Kit Creek Road 314 Research Triangle Park, NC 27709 315 US 317 Email: cpignata@cisco.com 319 Rajiv Asati 320 Cisco Systems 321 7025-6 Kit Creek Road 322 Research Triangle Park, NC 27709 323 US 325 Email: rajiva@cisco.com