idnits 2.17.1 draft-zheng-mpls-ldp-hello-crypto-auth-05.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 (July 16, 2012) is 4301 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-03 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: January 17, 2013 M. Bhatia 6 Alcatel-Lucent 7 July 16, 2012 9 LDP Hello Cryptographic Authentication 10 draft-zheng-mpls-ldp-hello-crypto-auth-05.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 January 17, 2013. 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 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 also used to maintain the relationship between LDP 99 peers necessary to keep the LDP session active. 101 Unlike other LDP messages, the Hello messages are sent using UDP and 102 not TCP. This implies that these messages cannot use the security 103 mechanisms defined for TCP [RFC5926]. Besides a note that some 104 configuration may help protect against bogus discovery messages, 105 [RFC5036] does not really provide any security mechanism to protect 106 the Hello messages. 108 Spoofing a Hello packet for an existing adjacency can cause the valid 109 adjacency to time out and in turn can result in termination of the 110 associated session. This can occur when the spoofed Hello specifies 111 a smaller Hold Time, causing the receiver to expect Hellos within 112 this smaller interval, while the true neighbor continues sending 113 Hellos at the previously agreed lower frequency. Spoofing a Hello 114 packet can also cause the LDP session to be terminated directly, 115 which can occur when the spoofed Hello specifies a different 116 Transport Address, other than the previously agreed one between 117 neighbors. Spoofed Hello messages have been observed and reported as 118 a real problem in production networks 119 [I-D.ietf-karp-routing-tcp-analysis]. 121 [RFC5036] describes that the threat of spoofed Basic Hellos can be 122 reduced by accepting Basic Hellos only on interfaces to which LSRs 123 that can be trusted are directly connected, and ignoring Basic Hellos 124 not addressed to the "all routers on this subnet" multicast group. 125 Spoofing attacks via Extended Hellos are a potentially more serious 126 threat. An LSR can reduce the threat of spoofed Extended Hellos by 127 filtering them and accepting only those originating at sources 128 permitted by an access list. However, filtering using access lists 129 requires LSR resource, and does not prevent IP-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. The LSRs could be configured to only accept 137 Hello messages from specific peers when authentication is in use. 139 Using this Cryptographic Authentication TLV, one or more secret keys 140 (with corresponding key IDs) are configured in each system. For each 141 LDP Hello packet, the key is used to generate and verify a HMAC Hash 142 that is stored in the LDP Hello packet. For cryptographic hash 143 function, this document proposes to use SHA-1, SHA-256, SHA-384, and 144 SHA-512 defined in US NIST Secure Hash Standard (SHS) [FIPS-180-3]. 145 The HMAC authentication mode defined in NIST FIPS 198 is used 146 [FIPS-198]. Of the above, implementations MUST include support for 147 at least HMAC-SHA-256 and SHOULD include support for HMAC-SHA-1 and 148 MAY include support for either of HMAC-SHA-384 or HMAC-SHA-512. 150 2. Cryptographic Authentication TLV 152 2.1. Optional Parameter for Hello Message 154 [RFC5036] defines the encoding for the Hello message. Each Hello 155 message contains zero or more Optional Parameters, each encoded as a 156 TLV. Three Optional Parameters are defined by [RFC5036]. This 157 document defines a new Optional Parameter: the Cryptographic 158 Authentication parameter. 160 Optional Parameter Type 161 ------------------------------- -------- 162 IPv4 Transport Address 0x0401 (RFC5036) 163 Configuration Sequence Number 0x0402 (RFC5036) 164 IPv6 Transport Address 0x0403 (RFC5036) 165 Cryptographic Authentication 0x0404 (this document, TBD by IANA) 167 The Cryptographic Authentication TLV Encoding is described in section 168 2.2. 170 2.2. Cryptographic Authentication TLV Encoding 172 0 1 2 3 173 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 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 |0|0| Auth (TBD) | Length | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Authentication Key ID | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Cryptographic Sequence Number (High Order 32 Bits) | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Cryptographic Sequence Number (Low Order 32 Bits) | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | | 184 | Authentication Data (Variable) | 185 ~ ~ 186 | | 187 | | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 - Type: TBD, Cryptographic Authentication 192 - Length: Specifying the length in octets of the value field. 194 - Auth Key ID: 32 bit field that identifies the algorithm and the 195 secret key used to create the message digest carried in LDP payload. 197 - Cryptographic Sequence Number: 64-bit strictly increasing sequence 198 number that is used to guard against replay attacks. The 64-bit 199 sequence number MUST be incremented for every LDP Hello packet sent 200 by the LDP router. Upon reception, the sequence number MUST be 201 greater than the sequence number in the last LDP Hello packet 202 accepted from the sending LDP neighbor. Otherwise, the LDP packet is 203 considered a replayed packet and dropped. 205 LDP routers implementing this specification SHOULD use available 206 mechanisms to preserve the sequence number's strictly increasing 207 property for the deployed life of the LDP router (including cold 208 restarts). One mechanism for accomplishing this could be to use the 209 high-order 32 bits of the sequence number as a wrap/boot count that 210 is incremented anytime the LDP router loses its sequence number 211 state. Techniques such as sequence number space partitioning 212 described above or non-volatile storage preservation can be used but 213 are really beyond the scope of this specification. 215 - Authentication Data: 217 This field carries the digest computed by the Cryptographic 218 Authentication algorithm in use. The length of the Authentication 219 Data varies based on the cryptographic algorithm in use, which is 220 shown as below: 222 Auth type Length 223 --------------- ---------- 224 HMAC-SHA1 20 bytes 225 HMAC-SHA-256 32 bytes 226 HMAC-SHA-384 48 bytes 227 HMAC-SHA-512 64 bytes 229 3. Cryptographic Aspects 231 In the algorithm description below, the following nomenclature, which 232 is consistent with [FIPS-198], is used: 234 - H is the specific hashing algorithm specified by Auth Type (e.g. 235 SHA-256). 237 - K is the Authentication Key for the Hello packet. 239 - Ko is the cryptographic key used with the hash algorithm. 241 - B is the block size of H, in octets. 243 For SHA-1 and SHA-256: B == 64 244 For SHA-384 and SHA-512: B == 128 246 - L is the length of the hash outputs, in octets. 248 - XOR is the exclusive-or operation. 250 - Ipad is the byte 0x36 repeated B times. 252 - Opad is the byte 0x5c repeated B times. 254 - Apad is source IP address that the would be used when sending out 255 the LDP packet, repeated L/4 times, where L is the length of the 256 hash, measured in octets. 258 3.1. Cryptographic Key 260 As described in [RFC2104], the authentication key K can be of any 261 length up to B. Applications that use keys longer than B bytes will 262 first hash the key using H and then use the resultant L byte string 263 as the actual key to HMAC. 265 In this application, Ko is always L octets long. If the 266 Authentication Key (K) is L octets long, then Ko is equal to K. If 267 the Authentication Key (K) is more than L octets long, then Ko is set 268 to H(K). If the Authentication Key (K) is less than L octets long, 269 then Ko is set to the Authentication Key (K) with trailing zeros such 270 that Ko is L octets long. 272 3.2. Hash 274 First, the Authentication Data field in the Cryptographic 275 Authentication TLV is filled with the value Apad. Then, to compute 276 HMAC over the Hello packet it performs: 278 H(Ko XOR Opad || H(Ko XOR Ipad || (Hello Packet))) 280 Hello Packet refers to the LDP Hello packet excluding the IP header. 282 3.3. Result 284 The resultant Hash becomes the Authentication Data that is sent in 285 the Authentication Data field of the Cryptographic Authentication 286 TLV. The length of the Authentication Data field is always identical 287 to the message digest size of the specific hash function H that is 288 being used. 290 4. Processing Hello Message Using Cryptographic Authentication 292 4.1. Transmission Using Cryptographic Authentication 294 Prior to transmitting Hello message, the Length in the Cryptographic 295 Authentication TLV header is set as per the authentication algorithm 296 that is being used. It is set to 24 for HMAC-SHA-1, 36 for HMAC-SHA- 297 256, 52 for HMAC-SHA-384 and 68 for HMAC-SHA-512. 299 The Auth Key ID field is set to the ID of the current authentication 300 key. The HMAC Hash is computed as explained in Section 3. The 301 resulting Hash is stored in the Authentication Data field prior to 302 transmission. The authentication key MUST NOT be carried in the 303 packet. 305 4.2. Receipt Using Cryptographic Authentication 307 The receiving LSR applies acceptability criteria for received Hellos 308 using cryptographic authentication. If the Cryptographic 309 Authentication TLV is unknown to the receiving LSR, the received 310 packet MUST be discarded according to Section 3.5.1.2.2 of [RFC5036]. 312 If the Auth Key ID field does not match the ID of a configured 313 authentication key, the received packet MUST be discarded. 315 If the cryptographic sequence number in the LDP packet is less than 316 or equal to the last sequence number received from the same neighbor, 317 the LDP packet MUST be discarded. 319 Before the receiving LSR performs any processing, it needs to save 320 the values of the Authentication Data field. The receiving LSR then 321 replaces the contents of the Authentication Data field with Apad, 322 computes the Hash, using the authentication key specified by the 323 received Auth Key ID field, as explained in Section 3. If the 324 locally computed Hash is equal to the received value of the 325 Authentication Data field, the received packet is accepted for other 326 normal checks and processing as described in [RFC5036]. Otherwise, 327 if the locally computed Hash is not equal to the received value of 328 the Authentication Data field, 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 unauthenticated LDP Hello messages. In order to address 334 those issues, it is RECOMMENDED that all deployments use the 335 Cryptographic Authentication TLV to authenticate 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 The IANA is requested to as assign a new TLV from the "Multiprotocol 368 Label Switching Architecture (MPLS) Label Switched Paths (LSPs) 369 Parameters - TLVs" registry, "TLVs and sub-TLVs" sub- registry. 371 Value Meaning Reference 372 ----- -------------------------------- --------- 373 TBD Cryptographic Authentication TLV this document (sect 3.2) 375 7. Acknowledgements 377 The authors would like to thank Liu Xuehu for his work on background 378 and motivation for LDP Hello authentication. The authors also would 379 like to thank Adrian Farrel, Eric Rosen, Sam Hartman, Eric Gray, 380 Kamran Raza and Acee Lindem for their valuable comments. 382 We would also like to thank the authors of RFC 5709 from where we 383 have taken most of the cryptographic computation procedures from. 385 8. References 387 8.1. Normative References 389 [FIPS-180-3] 390 "Secure Hash Standard (SHS), FIPS PUB 180-3", 391 October 2008. 393 [FIPS-198] 394 "The Keyed-Hash Message Authentication Code (HMAC), FIPS 395 PUB 198", March 2002. 397 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 398 Hashing for Message Authentication", RFC 2104, 399 February 1997. 401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 402 Requirement Levels", BCP 14, RFC 2119, March 1997. 404 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 405 Specification", RFC 5036, October 2007. 407 8.2. References 409 8.3. Informative References 411 [I-D.ietf-karp-routing-tcp-analysis] 412 Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 413 BGP, LDP, PCEP and MSDP Issues According to KARP Design 414 Guide", draft-ietf-karp-routing-tcp-analysis-03 (work in 415 progress), July 2012. 417 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 418 for the TCP Authentication Option (TCP-AO)", RFC 5926, 419 June 2010. 421 Authors' Addresses 423 Lianshu Zheng 424 Huawei Technologies 425 China 427 Email: vero.zheng@huawei.com 429 Mach(Guoyi) Chen 430 Huawei Technologies 431 China 433 Email: mach.chen@huawei.com 435 Manav Bhatia 436 Alcatel-Lucent 437 India 439 Email: manav.bhatia@alcatel-lucent.com