idnits 2.17.1 draft-ietf-mpls-ldp-hello-crypto-auth-09.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 (June 18, 2014) is 3597 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) == Unused Reference: 'RFC4822' is defined on line 622, but no explicit reference was found in the text == Unused Reference: 'RFC5310' is defined on line 629, but no explicit reference was found in the text == Unused Reference: 'RFC5709' is defined on line 633, but no explicit reference was found in the text == Unused Reference: 'RFC7166' is defined on line 650, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-3' ** Downref: Normative reference to an Informational RFC: RFC 2104 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 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: December 20, 2014 M. Bhatia 6 Ionos Networks 7 June 18, 2014 9 LDP Hello Cryptographic Authentication 10 draft-ietf-mpls-ldp-hello-crypto-auth-09.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 Hashed Message Authentication Code 19 (HMAC) with National Institute of Standards and Technology (NIST) 20 Secure Hash Standard family of algorithms. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 20, 2014. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Cryptographic Authentication TLV . . . . . . . . . . . . . . 4 64 2.1. Optional Parameter for Hello Message . . . . . . . . . . 4 65 2.2. LDP Security Association . . . . . . . . . . . . . . . . 4 66 2.3. Cryptographic Authentication TLV Encoding . . . . . . . . 6 67 2.4. Sequence Number Wrap . . . . . . . . . . . . . . . . . . 8 68 3. Cryptographic Authentication Procedure . . . . . . . . . . . 8 69 4. Cross Protocol Attack Mitigation . . . . . . . . . . . . . . 9 70 5. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . 9 71 5.1. Preparing the Cryptographic Key . . . . . . . . . . . . . 9 72 5.2. Computing the Hash . . . . . . . . . . . . . . . . . . . 10 73 5.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 6. Processing Hello Message Using Cryptographic Authentication . 10 75 6.1. Transmission Using Cryptographic Authentication . . . . . 10 76 6.2. Receipt Using Cryptographic Authentication . . . . . . . 11 77 7. Operational Considerations . . . . . . . . . . . . . . . . . 12 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 83 11.2. Informative References . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 86 1. Introduction 88 The Label Distribution Protocol (LDP) [RFC5036] sets up LDP sessions 89 that run between LDP peers. The peers could either be directly 90 connected at the link level or could be multiple hops away. An LDP 91 Label Switching Router (LSR) could either be configured with the 92 identity of its peers or could discover them using LDP Hello 93 messages. These messages are sent encapsulated in UDP addressed to 94 "all routers on this subnet" or to a specific IP address. Periodic 95 Hello messages are also used to maintain the relationship between LDP 96 peers necessary to keep the LDP session active. 98 Since the Hello messages are sent using UDP and not TCP, these 99 messages cannot use the security mechanisms defined for TCP 100 [RFC5926]. While some configuration guidance is given in [RFC5036] 101 to help protect against false discovery messages, it does not provide 102 an explicit security mechanism to protect the Hello messages. 104 Spoofing a Hello message for an existing adjacency can cause the 105 valid adjacency to time out and in turn can result in termination of 106 the associated session. This can occur when the spoofed Hello 107 specifies a smaller Hold Time, causing the receiver to expect Hellos 108 within this smaller interval, while the true neighbor continues 109 sending Hellos at the previously agreed lower frequency. Spoofing a 110 Hello message can also cause the LDP session to be terminated 111 directly, which can occur when the spoofed Hello specifies a 112 different Transport Address, other than the previously agreed one 113 between neighbors. Spoofed Hello messages have been observed and 114 reported as a real problem in production networks [RFC6952]. 116 For Link Hello, [RFC5036] states that the threat of spoofed Hellos 117 can be reduced by accepting Hellos only on interfaces to which LSRs 118 that can be trusted are directly connected, and ignoring Hellos not 119 addressed to the "all routers on this subnet" multicast group. The 120 Generalized TTL Security Mechanism (GTSM) provides a simple and 121 reasonably robust defense mechanism for Link Hello [RFC6720], but it 122 does not secure against packet spoofing attack or replay 123 attack[RFC5082]. 125 Spoofing attacks via Targeted Hellos are a potentially more serious 126 threat. [RFC5036] states that an LSR can reduce the threat of 127 spoofed Targeted Hellos by filtering them and accepting only those 128 originating at sources permitted by an access list. However, 129 filtering using access lists requires LSR resource, and does not 130 prevent IP-address spoofing. 132 This document introduces a new Cryptographic Authentication TLV which 133 is used in LDP Hello messages as an optional parameter. It enhances 134 the authentication mechanism for LDP by securing the Hello message 135 against spoofing attack. It also introduces a cryptographic sequence 136 number carried in the Hello messages that can be used to protect 137 against replay attacks. 139 Using this Cryptographic Authentication TLV, one or more secret keys 140 (with corresponding Security Association (SA) IDs) are configured in 141 each system. For each LDP Hello message, the key is used to generate 142 and verify a HMAC Hash that is stored in the LDP Hello message. For 143 cryptographic hash function, this document proposes to use SHA-1, 144 SHA-256, SHA-384, and SHA-512 defined in US NIST Secure Hash Standard 145 (SHS) [FIPS-180-3]. The HMAC authentication mode defined in 146 [RFC2104] is used. Of the above, implementations MUST include 147 support for at least HMAC-SHA-256 and SHOULD include support for 148 HMAC-SHA-1 and MAY include support for HMAC-SHA-384 and 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 TBD1 (this document, TBD1 by IANA) 167 The Cryptographic Authentication TLV Encoding is described in section 168 2.3. 170 2.2. LDP Security Association 172 An LDP Security Association (SA) contains a set of parameters shared 173 between any two legitimate LDP speakers. 175 Parameters associated with an LDP SA are as follows: 177 o Security Association Identifier (SA ID) 179 This is a 32-bit unsigned integer used to uniquely identify an LDP 180 SA between two LDP peers, as manually configured by the network 181 operator (or, possibly by some key management protocol specified 182 by the IETF in the future) . 184 The receiver determines the active SA by looking at the SA ID 185 field in the incoming Hello message. 187 The sender, based on the active configuration, selects an SA to 188 use and puts the correct SA ID value associated with the SA in the 189 LDP Hello message. If multiple valid and active LDP SAs exist for 190 a given interface, the sender may use any of those SAs to protect 191 the packet. 193 Using SA IDs makes changing keys while maintaining protocol 194 operation convenient. Each SA ID specifies two independent parts, 195 the authentication algorithm and the authentication key, as 196 explained below. 198 Normally, an implementation would allow the network operator to 199 configure a set of keys in a key chain, with each key in the chain 200 having fixed lifetime. The actual operation of these mechanisms 201 is outside the scope of this document. 203 Note that each SA ID can indicate a key with a different 204 authentication algorithm. This allows the introduction of new 205 authentication mechanisms without disrupting existing LDP 206 sessions. 208 o Authentication Algorithm 210 This signifies the authentication algorithm to be used with the 211 LDP SA. This information is never sent in clear text over the 212 wire. Because this information is not sent on the wire, the 213 implementer chooses an implementation specific representation for 214 this information. 216 Currently, the following algorithms are supported: 218 HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512. 220 o Authentication Key 222 This value denotes the cryptographic authentication key associated 223 with the LDP SA. The length of this key is variable and depends 224 upon the authentication algorithm specified by the LDP SA. 226 o KeyStartAccept 228 The time that this LDP router will accept packets that have been 229 created with this LDP Security Association. 231 o KeyStartGenerate 233 The time that this LDP router will begin using this LDP Security 234 Association for LDP Hello message generation. 236 o KeyStopGenerate 238 The time that this LDP router will stop using this LDP Security 239 Association for LDP Hello message generation. 241 o KeyStopAccept 243 The time that this LDP router will stop accepting packets 244 generated with this LDP Security Association. 246 In order to achieve smooth key transition, KeyStartAccept SHOULD be 247 less than KeyStartGenerate and KeyStopGenerate SHOULD be less than 248 KeyStopAccept. If KeyStartGenerate or KeyStartAccept are left 249 unspecified, the time will default to 0 and the key will be used 250 immediately. If KeyStopGenerate or KeyStopAccept are left 251 unspecified, the time will default to infinity and the key's lifetime 252 will be infinite. When a new key replaces an old, the 253 KeyStartGenerate time for the new key MUST be less than or equal to 254 the KeyStopGenerate time of the old key. Any unspecified values are 255 encoded as Zero. 257 Key storage SHOULD persist across a system restart, warm or cold, to 258 avoid operational issues. In the event that the last key associated 259 with an interface expires, it is unacceptable to revert to an 260 unauthenticated condition, and not advisable to disrupt routing. 261 Therefore, the router SHOULD send a "last Authentication Key 262 expiration" notification to the network manager and treat the key as 263 having an infinite lifetime until the lifetime is extended, the key 264 is deleted by network management, or a new key is configured. 266 2.3. Cryptographic Authentication TLV Encoding 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 |0|0| Auth (TBD1) | Length | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Security Association ID | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Cryptographic Sequence Number (High Order 32 Bits) | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Cryptographic Sequence Number (Low Order 32 Bits) | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | | 279 | Authentication Data (Variable) | 280 ~ ~ 281 | | 282 | | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 - Type: TBD1, Cryptographic Authentication 287 - Length: Specifying the length in octets of the value field, 288 including the Security Association ID and Cryptographic Sequence 289 Number fields. 291 - Security Association ID: 32 bit field that maps to the 292 authentication algorithm and the secret key used to create the 293 message digest carried in LDP payload. 295 Though the SA ID implies the algorithm, the HMAC output size should 296 not be used by implementers as an implicit hint, because additional 297 algorithms may be defined in the future that have the same output 298 size. 300 - Cryptographic Sequence Number: 64-bit strictly increasing sequence 301 number that is used to guard against replay attacks. The 64-bit 302 sequence number MUST be incremented for every LDP Hello message sent 303 by the LDP router. Upon reception, the sequence number MUST be 304 greater than the sequence number in the last LDP Hello message 305 accepted from the sending LDP neighbor. Otherwise, the LDP message 306 is considered a replayed packet and dropped. The Cryptographic 307 Sequence Number is a single space per LDP router. 309 LDP routers implementing this specification MUST use existing 310 mechanisms to preserve the sequence number's strictly increasing 311 property for the deployed life of the LDP router (including cold 312 restarts). One mechanism for accomplishing this could be to use the 313 high-order 32 bits of the sequence number as a boot count that is 314 incremented anytime the LDP router loses its sequence number state. 316 Techniques such as sequence number space partitioning described above 317 or non-volatile storage preservation can be used but are beyond the 318 scope of this specification. Sequence number wrap is described in 319 Section 2.4. 321 - Authentication Data: 323 This field carries the digest computed by the Cryptographic 324 Authentication algorithm in use. The length of the Authentication 325 Data varies based on the cryptographic algorithm in use, which is 326 shown as below: 328 Auth type Length 329 --------------- ---------- 330 HMAC-SHA1 20 bytes 331 HMAC-SHA-256 32 bytes 332 HMAC-SHA-384 48 bytes 333 HMAC-SHA-512 64 bytes 335 2.4. Sequence Number Wrap 337 When incrementing the sequence number for each transmitted LDP 338 message, the sequence number should be treated as an unsigned 64-bit 339 value. If the lower order 32-bit value wraps, the higher order 340 32-bit value should be incremented and saved in non-volatile storage. 341 If the LDP router is deployed long enough that the 64-bit sequence 342 number wraps, all keys, independent of key distribution mechanism 343 MUST be reset. This is done to avoid the possibility of replay 344 attacks. Once the keys have been changed, the higher order sequence 345 number can be reset to 0 and saved to non-volatile storage. 347 3. Cryptographic Authentication Procedure 349 As noted earlier, the Security Association ID maps to the 350 authentication algorithm and the secret key used to generate and 351 verify the message digest. This specification discusses the 352 computation of LDP Cryptographic Authentication data when any of the 353 NIST SHS family of algorithms is used in the Hashed Message 354 Authentication Code (HMAC) mode. 356 The currently valid algorithms (including mode) for LDP Cryptographic 357 Authentication include: 359 HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 and HMAC-SHA-512 361 Of the above, implementations of this specification MUST include 362 support for at least HMAC-SHA-256 and SHOULD include support for 363 HMAC-SHA-1 and MAY also include support for HMAC-SHA-384 and HMAC- 364 SHA-512. 366 Implementations of this standard MUST use HMAC-SHA-256 as the default 367 authentication algorithm. 369 4. Cross Protocol Attack Mitigation 371 In order to prevent cross protocol replay attacks for protocols 372 sharing common keys, the two octet LDP Cryptographic Protocol ID is 373 appended to the authentication key prior to use (refer to Section 8). 374 Other protocols using the common key similarly append their own 375 Cryptographic Protocol IDs to their keys prior to use thus ensuring 376 that a different key value is used for each protocol. 378 5. Cryptographic Aspects 380 In the algorithm description below, the following nomenclature is 381 used: 383 H is the specific hashing algorithm (e.g. SHA-256). 385 K is the Authentication Key from the LDP security association. 387 Ks is a Protocol Specific Authentication Key obtained by appending 388 Authentication Key (K) with the two-octet LDP Cryptographic Protocol 389 ID . 391 Ko is the cryptographic key used with the hash algorithm. 393 L is the length of the hash, measured in octets rather than bits. 395 AuthTag is a value which is the same length as the hash output. In 396 case of IPv4, the first 4 octets contain the IPv4 source address 397 followed by the hexadecimal value 0x878FE1F3 repeated (L-4)/4 times. 398 In case of IPv6, the first 16 octets contain the IPv6 source address 399 followed by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. 400 This implies that hash output is always a length of at least 16 401 octets. 403 5.1. Preparing the Cryptographic Key 405 The LDP Cryptographic Protocol ID is appended to the Authentication 406 Key (K) yielding a Protocol Specific Authentication Key (Ks). In 407 this application, Ko is always L octets long. Keys that are longer 408 than the bit length of the hash function are hashed to force them to 409 this length, as we describe below. Ks is computed as follows: 411 If the Protocol Specific Authentication Key (Ks) is L octets long, 412 then Ko is equal to Ks. If the Protocol Specific Authentication Key 413 (Ks) is more than L octets long, then Ko is set to H(Ks). If the 414 Protocol Specific Authentication Key (Ks) is less than L octets long, 415 then Ko is set to the Protocol Specific Authentication Key (Ks) with 416 zeros appended to the end of the Protocol Specific Authentication Key 417 (Ks) such that Ko is L octets long. 419 For higher entropy it is RECOMMENDED that Key Ks should be at least L 420 octets long. 422 5.2. Computing the Hash 424 First, the Authentication Data field in the Cryptographic 425 Authentication TLV is filled with the value AuthTag. Then, to 426 compute HMAC over the Hello message it performs: 428 AuthData = HMAC(Ko, Hello Message) 430 Hello Message refers to the LDP Hello message excluding the IP and 431 the UDP headers. 433 5.3. Result 435 The resultant Hash becomes the Authentication Data that is sent in 436 the Authentication Data field of the Cryptographic Authentication 437 TLV. The length of the Authentication Data field is always identical 438 to the message digest size of the specific hash function H that is 439 being used. 441 This also means that the use of hash functions with larger output 442 sizes will also increase the size of the LDP message as transmitted 443 on the wire. 445 6. Processing Hello Message Using Cryptographic Authentication 447 6.1. Transmission Using Cryptographic Authentication 449 Prior to transmitting the LDP Hello message, the Length in the 450 Cryptographic Authentication TLV header is set as per the 451 authentication algorithm that is being used. It is set to 24 for 452 HMAC-SHA-1, 36 for HMAC-SHA-256, 52 for HMAC-SHA-384 and 68 for HMAC- 453 SHA-512. 455 The Security Association ID field is set to the ID of the current 456 authentication key. The HMAC Hash is computed as explained in 457 Section 3. The resulting Hash is stored in the Authentication Data 458 field prior to transmission. The authentication key MUST NOT be 459 carried in the packet. 461 6.2. Receipt Using Cryptographic Authentication 463 The receiving LSR applies acceptability criteria for received Hellos 464 using cryptographic authentication. If the Cryptographic 465 Authentication TLV is unknown to the receiving LSR, the received 466 packet MUST be discarded according to Section 3.5.1.2.2 of [RFC5036]. 468 The receiving router MUST determine whether to accept a Hello Message 469 from a particular source IP address as follows. First, if the router 470 has, for that source IP address, any LDP Hello authentication 471 information, such as a stored cryptographic sequence number or that 472 LDP Hello authentication is required, then the router MUST discard 473 any unauthenticated Hello packets. As specified later in this 474 section, a cryptographic sequence number is only stored for a source 475 IP address as a result of receiving a valid authenticated Hello. 477 The receiving LSR locates the LDP SA using the Security Association 478 ID field carried in the message. If the SA is not found, or if the 479 SA is not valid for reception (i.e., current time < KeyStartAccept or 480 current time >= KeyStopAccept), LDP Hello message MUST be discarded, 481 and an error event SHOULD be logged. 483 If the cryptographic sequence number in the LDP Hello message is less 484 than or equal to the last sequence number received from the same 485 neighbor, the LDP Hello message MUST be discarded, and an error event 486 SHOULD be logged. 488 Before the receiving LSR performs any processing, it needs to save 489 the values of the Authentication Data field. The receiving LSR then 490 replaces the contents of the Authentication Data field with AuthTag, 491 computes the Hash, using the authentication key specified by the 492 received Security Association ID field, as explained in Section 3. 493 If the locally computed Hash is equal to the received value of the 494 Authentication Data field, the received packet is accepted for other 495 normal checks and processing as described in [RFC5036]. Otherwise, 496 if the locally computed Hash is not equal to the received value of 497 the Authentication Data field, the received LDP Hello message MUST be 498 discarded, and an error event SHOULD be logged. The foresaid logging 499 need to be carefully rate limited, since while a LDP router is under 500 attack of a storm of spoofed hellos, the resource taking for logging 501 could be overwelming. 503 After the LDP Hello message has been successfully authenticated, 504 implementations MUST store the 64-bit cryptographic sequence number 505 for the LDP Hello message received from the neighbor. The saved 506 cryptographic sequence numbers will be used for replay checking for 507 subsequent packets received from the neighbor. 509 7. Operational Considerations 511 Careful consideration must be given to when and how to enable and 512 disable authentication on LDP Hellos. On the one hand, it is 513 critical that an attack cannot cause the authentication to be 514 disabled. On the other hand, it is equally important that an 515 operator can change the hardware and/or software associated with a 516 neighbor's IP address and successfully bring up an LDP adjacency with 517 the desired level of authentication, which may be with different or 518 no authentication due to software restrictions. 520 LDP Hello authentication information (e.g. whether authentication is 521 enabled and what the last cryptographic sequence number is) 522 associated with an IP address is learned via a set of interfaces. If 523 an interface is administratively disabled, the LDP Hello 524 authentication information learned via that interface MAY be 525 forgotten. This enables an operator that is not specifically 526 manipulating LDP Hello authentication configurations to easily bring 527 up an LDP adjacency. An implementation of this standard SHOULD 528 provide a configuration mechanism by which the LDP Hello 529 authentication information associated with an IP address can be shown 530 and can be forgotten; configuration mechanisms are assumed to be 531 accessed via an authenticated channel. 533 8. Security Considerations 535 Section 1 of this document describes the security issues arising from 536 the use of unauthenticated LDP Hello messages. In order to address 537 those issues, it is RECOMMENDED that all deployments use the 538 Cryptographic Authentication TLV to authenticate the Hello messages. 540 The quality of the security provided by the Cryptographic 541 Authentication TLV depends completely on the strength of the 542 cryptographic algorithm in use, the strength of the key being used, 543 and the correct implementation of the security mechanism in 544 communicating LDP implementations. Also, the level of security 545 provided by the Cryptographic Authentication TLV varies based on the 546 authentication type used. 548 It should be noted that the authentication method described in this 549 document is not being used to authenticate the specific originator of 550 a packet but is rather being used to confirm that the packet has 551 indeed been issued by a router that has access to the Authentication 552 Key. 554 Deployments SHOULD use sufficiently long and random values for the 555 Authentication Key so that guessing and other cryptographic attacks 556 on the key are not feasible in their environments. In support of 557 these recommendations, management systems SHOULD support hexadecimal 558 input of Authentication Keys. 560 The mechanism described herein is not perfect . However, this 561 mechanism introduces a significant increase in the effort required 562 for an adversary to successfully attack the LDP Hello protocol while 563 not causing undue implementation, deployment, or operational 564 complexity. 566 9. IANA Considerations 568 The IANA is requested to as assign a new TLV from the "Label 569 Distribution Protocol (LDP) Parameters" registry, "TLV Type Name 570 Space". 572 Value Meaning Reference 573 ----- -------------------------------- ------------------------ 574 TBD1 Cryptographic Authentication TLV this document (sect 2.3) 576 The IANA is also requested to as assign value from the 577 "Authentication Cryptographic Protocol ID", registry under the 578 "Keying and Authentication for Routing Protocols (KARP) Parameters" 579 category. 581 Value Description Reference 582 ----- -------------------------------- ---------------------- 583 TBD2 LDP Cryptographic Protocol ID this document (sect 4) 585 Note to the RFC Editor and IANA (to be removed before publication): 587 The new value should be assigned from the range 0x400 - 0x4ff using 588 the first free value. 590 10. Acknowledgements 592 We are indebted to Yaron Sheffer who helped us enormously in 593 rewriting the draft to get rid of the redundant crypto mathematics 594 that we had added here. 596 We would also like to thank Liu Xuehu for his work on background and 597 motivation for LDP Hello authentication. And last but not the least, 598 we would also thank Adrian Farrel, Eric Rosen, Sam Hartman, Stephen 599 Farrell, Eric Gray, Kamran Raza and Acee Lindem for their valuable 600 comments. 602 11. References 604 11.1. Normative References 606 [FIPS-180-3] 607 "Secure Hash Standard (SHS), FIPS PUB 180-3", October 608 2008. 610 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 611 Hashing for Message Authentication", RFC 2104, February 612 1997. 614 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 615 Requirement Levels", BCP 14, RFC 2119, March 1997. 617 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 618 Specification", RFC 5036, October 2007. 620 11.2. Informative References 622 [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic 623 Authentication", RFC 4822, February 2007. 625 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 626 Pignataro, "The Generalized TTL Security Mechanism 627 (GTSM)", RFC 5082, October 2007. 629 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 630 and M. Fanto, "IS-IS Generic Cryptographic 631 Authentication", RFC 5310, February 2009. 633 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 634 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 635 Authentication", RFC 5709, October 2009. 637 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 638 for the TCP Authentication Option (TCP-AO)", RFC 5926, 639 June 2010. 641 [RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security 642 Mechanism (GTSM) for the Label Distribution Protocol 643 (LDP)", RFC 6720, August 2012. 645 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 646 BGP, LDP, PCEP, and MSDP Issues According to the Keying 647 and Authentication for Routing Protocols (KARP) Design 648 Guide", RFC 6952, May 2013. 650 [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting 651 Authentication Trailer for OSPFv3", RFC 7166, March 2014. 653 Authors' Addresses 655 Lianshu Zheng 656 Huawei Technologies 657 China 659 Email: vero.zheng@huawei.com 661 Mach(Guoyi) Chen 662 Huawei Technologies 663 China 665 Email: mach.chen@huawei.com 667 Manav Bhatia 668 Ionos Networks 669 India 671 Email: manav@ionosnetworks.com