idnits 2.17.1 draft-zheng-mpls-ldp-hello-crypto-auth-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 -- The document date (May 10, 2012) is 4359 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-198' ** Downref: Normative reference to an Informational RFC: RFC 2104 == Outdated reference: A later version (-07) exists of draft-ietf-karp-routing-tcp-analysis-01 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Zheng 3 Internet-Draft M. Chen 4 Intended status: Standards Track Huawei Technologies 5 Expires: November 11, 2012 M. Bhatia 6 Alcatel-Lucent 7 May 10, 2012 9 LDP Hello Cryptographic Authentication 10 draft-zheng-mpls-ldp-hello-crypto-auth-04.txt 12 Abstract 14 This document introduces a new optional Cryptographic Authentication 15 TLV that LDP can use to secure its Hello messages. It secures the 16 Hello messages against spoofing attacks and some well known attacks 17 against the IP header. This document describes a mechanism to secure 18 the LDP Hello messages using National Institute of Standards and 19 Technology (NIST) Secure Hash Standard family of algorithms. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 11, 2012. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Cryptographic Authentication TLV . . . . . . . . . . . . . . . 6 64 2.1. Optional Parameter for Hello Message . . . . . . . . . . . 6 65 2.2. Cryptographic Authentication TLV Encoding . . . . . . . . 6 67 3. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . 8 68 3.1. Cryptographic Key . . . . . . . . . . . . . . . . . . . . 8 69 3.2. Hash . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 4. Processing Hello Message Using Cryptographic Authentication . 10 73 4.1. Transmission Using Cryptographic Authentication . . . . . 10 74 4.2. Receipt Using Cryptographic Authentication . . . . . . . . 10 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 84 8.2. References . . . . . . . . . . . . . . . . . . . . . . . . 14 85 8.3. Informative References . . . . . . . . . . . . . . . . . . 14 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 89 1. Introduction 91 The Label Distribution Protocol (LDP) [RFC5036] sets up LDP sessions 92 that runs between LDP peers. The peers could either be directly 93 connected at the link level or could be multiple hops away. An LDP 94 Label Switching Router (LSR) could either be configured with the 95 identity of its peers or could discover them using the LDP Hello 96 messages. These messages are sent encapsulated in UDP addressed to 97 "all routers on this subnet" or to a specific IP address. Periodic 98 Hello messages are sent to keep the LDP sessions alive. 100 Unlike other LDP messages, the Hello messages are sent using UDP and 101 not TCP. This implies that these messages can not use the security 102 mechanisms defined for TCP [RFC5926]. [RFC5036], besides a note that 103 some configuration may help protect against bogus discovery messages, 104 does not really provide any security mechanism to protect the Hello 105 messages. 107 Spoofing a Hello packet for an existing adjacency can cause the valid 108 adjacency to time out and in turn can result in termination of the 109 associated session. This can occur when the spoofed Hello specifies 110 a smaller Hold Time, causing the receiver to expect Hellos within 111 this smaller interval, while the true neighbor continues sending 112 Hellos at the previously agreed lower frequency. Spoofing a Hello 113 packet can also cause the LDP session to be terminated directly, 114 which can occur when the spoofed Hello specifies a different 115 Transport Address, other than the previously agreed one between 116 neighbors. Spoofed Hello messages have been observed and reported as 117 a real problem in production networks 118 [I-D.ietf-karp-routing-tcp-analysis]. 120 [RFC5036] describes that the threat of spoofed Basic Hellos can be 121 reduced by accepting Basic Hellos only on interfaces to which LSRs 122 that can be trusted, and ignoring Basic Hellos not addressed to the 123 "all routers on this subnet" multicast group. Spoofing attacks via 124 Extended Hellos are potentially more serious threat. An LSR can 125 reduce the threat of spoofed Extended Hellos by filtering them and 126 accepting only those originating at sources permitted by an access 127 list. However, performing the filtering using access lists requires 128 LSR resource, and the LSR is still vulnerable to the IP source 129 address spoofing. 131 This document introduces a new Cryptographic Authentication TLV which 132 is used in LDP Hello message as an optional parameter. It enhances 133 the authentication mechanism for LDP by securing the Hello message 134 against spoofing attack. It also introduces a cryptographic sequence 135 number carried in the Hello messages that can be used to protect 136 against replay attacks. As a further step in security, the LSRs 137 could be configured to only accept Hello messages from specific peers 138 when authentication is in use. 140 Using this Cryptographic Authentication TLV, one or more secret keys 141 (with corresponding key IDs) are configured in each system. For each 142 LDP Hello packet, the key is used to generate and verify a HMAC Hash 143 that is stored in the LDP Hello packet. For cryptographic hash 144 function, this document proposes to use SHA-1, SHA-256, SHA-384, and 145 SHA-512 defined in US NIST Secure Hash Standard (SHS) [FIPS-180-3]. 146 The HMAC authentication mode defined in NIST FIPS 198 is used 147 [FIPS-198]. Of the above, implementations MUST include support for 148 at least HMAC-SHA-256 and SHOULD include support for HMAC-SHA-1 and 149 MAY include support for either of HMAC-SHA-384 or HMAC-SHA-512. 151 2. Cryptographic Authentication TLV 153 2.1. Optional Parameter for Hello Message 155 [RFC5036] defines the encoding for the Hello message. Each Hello 156 message contains zero or more Optional Parameters, each encoded as a 157 TLV. Three Optional Parameters are defined by [RFC5036]. This 158 document defines a new Optional Parameter: the Cryptographic 159 Authentication parameter. 161 Optional Parameter Type 162 ------------------------------- -------- 163 IPv4 Transport Address 0x0401 (RFC5036) 164 Configuration Sequence Number 0x0402 (RFC5036) 165 IPv6 Transport Address 0x0403 (RFC5036) 166 Cryptographic Authentication 0x0404 (this document, TBD by IANA) 168 The Cryptographic Authentication TLV Encoding is described in section 169 2.2. 171 2.2. Cryptographic Authentication TLV Encoding 173 0 1 2 3 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 |0|0| Auth (0x0404) | Length | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Authentication Key ID | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Cryptographic Sequence Number (High Order 32 Bits) | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Cryptographic Sequence Number (Low Order 32 Bits) | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | | 185 | Authentication Data (Variable) | 186 ~ ~ 187 | | 188 | | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 - Type: 0x0404 (TBD by IANA), Cryptographic Authentication 193 - Length: Specifying the length in octets of the value field. 195 - Auth Key ID: 32 bit field that identifies the algorithm and the 196 secret key used to create the message digest carried in LDP payload. 198 - Cryptographic Sequence Number: 64-bit strictly increasing sequence 199 number that is used to guard against replay attacks. The 64-bit 200 sequence number MUST be incremented for every LDP Hello packet sent 201 by the LDP router. Upon reception, the sequence number MUST be 202 greater than the sequence number in the last LDP Hello packet 203 accepted from the sending LDP neighbor. Otherwise, the LDP packet is 204 considered a replayed packet and dropped. 206 LDP routers implementing this specification SHOULD use available 207 mechanisms to preserve the sequence number's strictly increasing 208 property for the deployed life of the LDP router (including cold 209 restarts). One mechanism for accomplishing this could be to use the 210 high-order 32 bits of the sequence number as a wrap/boot count that 211 is incremented anytime the LDP router loses its sequence number 212 state. Techniques such as sequence number space partitioning 213 described above or non-volatile storage preservation can be used but 214 are really beyond the scope of this specification. 216 - Authentication Data: 218 This field carries the digest computed by the Cryptographic 219 Authentication algorithm in use. The length of the Authentication 220 Data varies based on the cryptographic algorithm in used, which is 221 shown as below: 223 Auth type Length 224 --------------- ---------- 225 HMAC-SHA1 20 bytes 226 HMAC-SHA-256 32 bytes 227 HMAC-SHA-384 48 bytes 228 HMAC-SHA-512 64 bytes 230 3. Cryptographic Aspects 232 In the algorithm description below, the following nomenclature, which 233 is consistent with [FIPS-198], is used: 235 - H is the specific hashing algorithm specified by Auth Type (e.g. 236 SHA-256). 238 - K is the Authentication Key for the Hello packet. 240 - Ko is the cryptographic key used with the hash algorithm. 242 - B is the block size of H, in octets. 244 For SHA-1 and SHA-256: B == 64 245 For SHA-384 and SHA-512: B == 128 247 - L is the length of the hash outputs, in octets. 249 - XOR is the exclusive-or operation. 251 - Ipad is the byte 0x36 repeated B times. 253 - Opad is the byte 0x5c repeated B times. 255 - Apad is source IP address that the would be used when sending out 256 the LDP packet, repeated L/4 times, where L is the length of the 257 hash, measured in octets. 259 3.1. Cryptographic Key 261 As described in [RFC2104], the authentication key K can be of any 262 length up to B. Applications that use keys longer than B bytes will 263 first hash the key using H and then use the resultant L byte string 264 as the actual key to HMAC. 266 In this application, Ko is always L octets long. If the 267 Authentication Key (K) is L octets long, then Ko is equal to K. If 268 the Authentication Key (K) is more than L octets long, then Ko is set 269 to H(K). If the Authentication Key (K) is less than L octets long, 270 then Ko is set to the Authentication Key (K) with trailing zeros such 271 that Ko is L octets long. 273 3.2. Hash 275 First, the Authentication Data field in the Cryptographic 276 Authentication TLV is filled with the value Apad. Then, to compute 277 HMAC over the Hello packet it performs: 279 H(Ko XOR Opad || H(Ko XOR Ipad || (Hello Packet))) 281 Hello Packet refers to the LDP Hello packet excluding the IP header. 283 3.3. Result 285 The resultant Hash becomes the Authentication Data that is sent in 286 the Authentication Data field of the Cryptographic Authentication 287 TLV. The length of the Authentication Data field is always identical 288 to the message digest size of the specific hash function H that is 289 being used. 291 4. Processing Hello Message Using Cryptographic Authentication 293 4.1. Transmission Using Cryptographic Authentication 295 Prior to transmitting Hello message, the Length in the Cryptographic 296 Authentication TLV header is set as per the authentication algorithm 297 that is being used. It is set to 24 for HMAC-SHA-1, 36 for HMAC-SHA- 298 256, 52 for HMAC-SHA-384 and 68 for HMAC-SHA-512. 300 The Auth Key ID field is set to the ID of the current authentication 301 key. The HMAC Hash is computed as explained in Section 3. The 302 resulting Hash is stored in the Authentication Data field prior to 303 transmission. The authentication key MUST NOT be carried in the 304 packet. 306 4.2. Receipt Using Cryptographic Authentication 308 The receiving LSR applies acceptability criteria for received Hellos 309 using cryptographic authentication. If the Cryptographic 310 Authentication TLV is unknown to the receiving LSR, the received 311 packet MUST be discarded according to Section 3.5.1.2.2 of [RFC5036]. 313 If the Auth Key ID field does not match the ID of a configured 314 authentication key, the received packet MUST be discarded. 316 If the cryptographic sequence number in the LDP packet is less than 317 or equal to the last sequence number received from the same neighbor, 318 the LDP packet MUST be discarded. 320 Before the receiving LSR performs any processing, it needs to save 321 the values of the Authentication Data field. The receiving LSR then 322 replaces the contents of the Authentication Data field with Apad, 323 computes the Hash, using the authentication key specified by the 324 received Auth Key ID field, as explained in Section 3. If the 325 locally computed Hash is equal to the received value of the 326 Authentication Data field, the received packet is accepted for other 327 normal checks and processing as described in [RFC5036]. Otherwise, 328 the received packet MUST be discarded. 330 5. Security Considerations 332 Section 1 of this document describes the security issues arising from 333 the use of unsecured LDP Hello messages. In order to address those 334 issues, it is RECOMMENDED that all deployments use the Cryptographic 335 Authentication TLV to secure the Hello messages. 337 The quality of the security provided by the Cryptographic 338 Authentication TLV depends completely on the strength of the 339 cryptographic algorithm in use, the strength of the key being used, 340 and the correct implementation of the security mechanism in 341 communicating LDP implementations. Also, the level of security 342 provided by the Cryptographic Authentication TLV varies based on the 343 authentication type used. 345 It should be noted that the authentication method described in this 346 document is not being used to authenticate the specific originator of 347 a packet but is rather being used to confirm that the packet has 348 indeed been issued by a router that has access to the Authentication 349 Key. 351 Deployments SHOULD use sufficiently long and random values for the 352 Authentication Key so that guessing and other cryptographic attacks 353 on the key are not feasible in their environments. Furthermore, it 354 is RECOMMENDED that Authentication Keys incorporate at least 128 355 pseudo-random bits to minimize the risk of such attacks. In support 356 of these recommendations, management systems SHOULD support 357 hexadecimal input of Authentication Keys. 359 The mechanism described herein is not perfect and does not need to be 360 perfect. Instead, this mechanism represents a significant increase 361 in the effort required for an adversary to successfully attack the 362 LDP Hello protocol while not causing undue implementation, 363 deployment, or operational complexity. 365 6. IANA Considerations 367 IANA maintains a registry of LDP message parameters with a sub- 368 registry to track LDP TLV Types. This document requests IANA to 369 assign a new TLV type as follows for Cryptographic Authenticatio. 370 This document suggests 0x0404 to foster pre-standard implementations. 372 7. Acknowledgements 374 The authors would like to thank Liu Xuehu for his work on background 375 and motivation for LDP Hello authentication. The authors also would 376 like to thank Adrian Farrel, Thomas Nadeau, So Ning, Eric Rosen and 377 Sam Hartman for their valuable comments. 379 We would also like to thank the authors of RFC 5709 from where we 380 have taken most of the cryptographic computation procedures from. 382 8. References 384 8.1. Normative References 386 [FIPS-180-3] 387 "Secure Hash Standard (SHS), FIPS PUB 180-3", 388 October 2008. 390 [FIPS-198] 391 "The Keyed-Hash Message Authentication Code (HMAC), FIPS 392 PUB 198", March 2002. 394 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 395 Hashing for Message Authentication", RFC 2104, 396 February 1997. 398 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 399 Requirement Levels", BCP 14, RFC 2119, March 1997. 401 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 402 Specification", RFC 5036, October 2007. 404 8.2. References 406 8.3. Informative References 408 [I-D.ietf-karp-routing-tcp-analysis] 409 Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 410 BGP, LDP, PCEP, and MSDP Security According to KARP Design 411 Guide", draft-ietf-karp-routing-tcp-analysis-01 (work in 412 progress), March 2012. 414 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 415 for the TCP Authentication Option (TCP-AO)", RFC 5926, 416 June 2010. 418 Authors' Addresses 420 Lianshu Zheng 421 Huawei Technologies 422 China 424 Email: verozheng@huawei.com 426 Mach(Guoyi) Chen 427 Huawei Technologies 428 China 430 Email: mach@huawei.com 432 Manav Bhatia 433 Alcatel-Lucent 434 India 436 Email: manav.bhatia@alcatel-lucent.com