idnits 2.17.1 draft-asati-pignataro-mpls-ldp-gtsm-01.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 (March 11, 2011) is 4793 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-00 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: September 12, 2011 March 11, 2011 7 The Generalized TTL Security Mechanism (GTSM) for Label Distribution 8 Protocol (LDP) 9 draft-asati-pignataro-mpls-ldp-gtsm-01 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 September 12, 2011. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.3. GTSM Sending and Receiving Procedures for LDP 63 Initialization . . . . . . . . . . . . . . . . . . . . . . 5 64 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 66 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 69 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 LDP [RFC5036] specifies two Discovery mechanisms, a Basic one and an 75 Extended one, both using UDP transport. The Basic Discovery 76 mechanism is used to discover LSR neighbors that are directly 77 connected at the link level, whereas the Extended Discovery mechanism 78 is used to locate LSR neighbors that are not directly connected at 79 the link level. Once discovered (or located), the LSR neighbors can 80 establish the LDP peering session, using the TCP transport 81 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 While GTSM specifies that it SHOULD NOT be enabled by default in 103 order to remain backward-compatible with the unmodified protocol, 104 this document specifies having GTSM for LDP be enabled by default but 105 not be enforced unless both peers can detect each others' support for 106 GTSM procedures as described in this document. 108 1.1. Specification of Requirements 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 1.2. Scope 116 This document defines procedures for LDP using IPv4 routing, but not 117 for LDP using IPv6 routing, since the latter has GTSM built into the 118 protocol definition [I-D.ietf-mpls-ldp-ipv6]. 120 Additionally, this document applies to LDP peering sessions set up 121 using Basic Discovery only. LDP peering sessions set up using 122 Extended Discovery are outside the scope of this document (see 123 Section 5.5 of [RFC5082]). 125 2. GTSM Procedures for LDP 127 2.1. GTSM Flag in Common Hello Parameter TLV 129 A new flag in Common Hello Parameter TLV, named G flag (for GTSM), is 130 defined by this document. An LSR indicates that it is capable of 131 applying GTSM procedures, as defined in this document, to the 132 subsequent LDP peering session, by setting the GTSM flag to 1. The 133 Common Hello Parameters TLV, defined in Section 3.5.2 of [RFC5036], 134 is updated as shown in Figure 1. 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 |0|0| Common Hello Parms(0x0400)| Length | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Hold Time |T|R|G| Reserved | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 G, GTSM 145 A value of 1 specifies that this LSR wishes to support GTSM 146 procedures, where a value of 0 specifies that this LSR does not 147 wish to support GTSM. 149 Figure 1: GTSM Flag in Common Hello Parameter TLV 151 The G flag is meaingful only if T and R flags are set to 0 (which 152 must be the case for Basic Discovery), otherwise, the value of G flag 153 should be ignored on receipt. 155 Any LSR not supporting GTSM for LDP, as defined in this document, 156 would continue to ignore the G flag, independent of T and R flags' 157 value, as per Section 3.5.2 of [RFC5036]. 159 2.2. GTSM Sending and Receiving Procedures for LDP Link Hello 161 Firstly, LSRs using LDP Basic Discovery [RFC5036] send LDP Hello 162 messages to link-level multicast address (224.0.0.2 or "all 163 routers"). Such messages are never forwarded beyond one hop and 164 assumed to have their IP TTL or Hop Count = 1. 166 An LSR may indicate that it is capable of applying GTSM procedures to 167 the subsequent TCP/LDP peering session by setting the G flag (for 168 GTSM) to 1 in Common Hello Parameter TLV in the LDP Link Hello 169 message [RFC5036]. 171 An LSR, upon receiving an LDP Link Hello message, would recognize the 172 presence of G flag (in Common Hello Parameter TLV) only if it 173 supports GTSM for LDP, as specified in this document. If an LSR 174 recognizes the presence of G flag with the value =1 in the received 175 LDP Link Hello message, then it must enforce GTSM for LDP in the 176 subsequent TCP/LDP peering session with the neighbor that sent the 177 Hello message, as specified in Section 2.3 of this document. 179 If an LSR does not recognize the presence of G flag (in Common Hello 180 Parameter TLV of Link Hello message), or recognizes the presence of G 181 flag with the value = 0, then the LSR must not enforce GTSM for LDP 182 in the subsequent TCP/LDP peering session with the neighbor that sent 183 the Hello message. This ensures backward compatibility as well as 184 automatic GTSM de-activation. 186 If an LSR that has sent the LDP Link Hello with G flag = 1, then the 187 LSR must set IP TTL or Hop Count = 255 in the forthcoming Transport 188 Connection(s) with that neighbor (LSR2, say). Please see Section 2.3 189 for more details about the TCP transport connection specifics. 191 2.3. GTSM Sending and Receiving Procedures for LDP Initialization 193 If an LSR that has sent and received LDP Link Hello with G flag = 1 194 from the directly-connected neighbor (LSR2, say), then the LSR must 195 enforce GTSM procedures, as defined in Section 3 of [RFC5082], in the 196 forthcoming Transport Connection with that neighbor (LSR2, say). 197 This means that the LSR must check for the incoming unicast packets' 198 TTL or Hop Count to be 255 for the particular LDP/TCP peering session 199 and decide the further processing as per the [RFC5082]. 201 If an LSR that has sent LDP Link Hello with G flag = 1, but received 202 LDP Link Hello with G flag = 0 from the directly-connected neighbor 203 (LSR3, say), then the LSR must not enforce GTSM procedures, as 204 defined in Section 3 of [RFC5082], in the forthcoming Transport 205 Connection with that neighbor (LSR2, say). 207 3. IANA Considerations 209 IANA is requested to assign the G, GTSM bit in the Common Hello 210 Parameters TLV (see Figure 1 in Section 2.1), as per allocation 211 policy defined at [I-D.asati-pignataro-mpls-ldp-iana]. 213 4. Security Considerations 215 This document increases the security for LDP, making it more 216 resilient to off-link attacks. 218 5. Acknowledgments 220 The authors of this document do not make any claims on the 221 originality of the ideas described. The concept of GTSM for LDP has 222 been proposed a number of times, and is documented in both the 223 Experimental and Standards Track specifications of GTSM. Among other 224 people, we would like to acknowledge Enke Chen and Albert Tian for 225 their document "TTL-Based Security Option for the LDP Hello Message". 227 6. References 229 6.1. Normative References 231 [I-D.asati-pignataro-mpls-ldp-iana] 232 Pignataro, C. and R. Asati, "Label Distribution Protocol 233 (LDP) Internet Assigned Numbers Authority (IANA) 234 Considerations Update", 235 draft-asati-pignataro-mpls-ldp-iana-01 (work in progress), 236 March 2011. 238 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 239 Requirement Levels", BCP 14, RFC 2119, March 1997. 241 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 242 Specification", RFC 5036, October 2007. 244 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 245 Pignataro, "The Generalized TTL Security Mechanism 246 (GTSM)", RFC 5082, October 2007. 248 6.2. Informative References 250 [I-D.ietf-mpls-ldp-ipv6] 251 Manral, V., Papneja, R., and R. Asati, "Updates to LDP for 252 IPv6", draft-ietf-mpls-ldp-ipv6-00 (work in progress), 253 November 2010. 255 Authors' Addresses 257 Carlos Pignataro 258 Cisco Systems 259 7200-12 Kit Creek Road 260 Research Triangle Park, NC 27709 261 US 263 Email: cpignata@cisco.com 265 Rajiv Asati 266 Cisco Systems 267 7025-6 Kit Creek Road 268 Research Triangle Park, NC 27709 269 US 271 Email: rajiva@cisco.com