idnits 2.17.1 draft-ietf-karp-ospf-analysis-06.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 26 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 26, 2012) is 4140 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4552' is defined on line 459, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-opsec-routing-protocols-crypto-issues' is defined on line 482, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-karp-threats-reqs-06 == Outdated reference: A later version (-10) exists of draft-ietf-karp-crypto-key-table-04 == Outdated reference: A later version (-10) exists of draft-ietf-karp-ops-model-04 == Outdated reference: A later version (-11) exists of draft-ietf-ospf-security-extension-manual-keying-03 -- Obsolete informational reference (is this intentional?): RFC 6506 (Obsoleted by RFC 7166) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 KARP S. Hartman 3 Internet-Draft Painless Security 4 Intended status: Informational D. Zhang 5 Expires: May 30, 2013 Huawei Technologies co. ltd 6 November 26, 2012 8 Analysis of OSPF Security According to KARP Design Guide 9 draft-ietf-karp-ospf-analysis-06.txt 11 Abstract 13 This document analyzes OSPFv2 and OSPFv3 according to the guidelines 14 set forth in section 4.2 of RFC6518. Key components of solutions to 15 gaps identified in this draft are already underway. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 30, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements to Meet . . . . . . . . . . . . . . . . . . . 3 59 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 4 60 2. Current State . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Impacts of OSPF Replays . . . . . . . . . . . . . . . . . . . 6 64 4. Gap Analysis and Specific Requirements . . . . . . . . . . . . 8 65 5. Solution Work . . . . . . . . . . . . . . . . . . . . . . . . 9 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 71 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 74 1. Introduction 76 This document analyzes the current state of OSPFv2 and OSPFv3 77 according to the requirements of [RFC6518]. This draft builds on 78 several previous analysis efforts into routing security. The OPSEC 79 working group put together [RFC6039] an analysis of cryptographic 80 issues with routing protocols. Earlier, the RPSEC working group put 81 together [I-D.ietf-rpsec-ospf-vuln] a detailed analysis of OSPF 82 vulnerabilities. Solution work to address gaps identified in this 83 analysis is underway [I-D.ietf-ospf-security-extension-manual-keying] 84 [RFC6506] 86 OSPF meets many of the requirements expected from a manually keyed 87 routing protocol. Integrity protection is provided with modern 88 cryptographic algorithms. Algorithm agility is provided: the 89 algorithm can be changed as part of re-keying an interface or peer. 90 Intra-connection re-keying is provided by the specifications, 91 although apparently some implementations have trouble with this in 92 practice. OSPFv2 security does not interfere with prioritization of 93 packets. 95 However, some gaps remain between the current state and the 96 requirements for manually keyed routing security expressed in 97 [I-D.ietf-karp-threats-reqs]. This document explores these gaps and 98 proposes directions for addressing the gaps. 100 1.1. Requirements to Meet 102 There are a number of requirements described in section 3 of 103 [I-D.ietf-karp-threats-reqs] that OSPF does not currently meet. The 104 gaps are as follows: 106 o Secure Simple PSKs: Today, OSPF directly uses the key as 107 specified. Related key attacks such as those described in section 108 4.1 of [I-D.ietf-karp-ops-model] are possible. 110 o Replay Protection: The requirements document addresses 111 requirements for both inter-connection replay protection and 112 intra-connection replay protection. OSPFv3 has no replay 113 protection at all. OSPFv2 has most of the mechanisms necessary 114 for intra-connection replay protection. Unfortunately, OSPFv2 115 does not securely identify the neighbor with whom replay 116 protection state is associated in all cases. This weakness can be 117 used to create significant denial-of- service issues using intra- 118 connection replays. OSPFv2 has no inter-connection replay 119 protection; this creates significant denial-of-service 120 opportunities. 122 o Packet Prioritization: OSPFv3 uses IPsec [RFC4301]to process 123 packets. This complicates implementations that wish to process 124 some packets such as hellos and acknowledgements above others. In 125 addition, if IPsec replay mechanisms were used, packets would need 126 to be processed at least by IPsec even if they were low priority. 128 o Neighbor Identification: In some cases, OSPF identifies a neighbor 129 based on the IP address. This is never protected with OSPFv2 and 130 is not typically protected with OSPFv3. 132 The remainder of this document explains the details of how these 133 requirements fail to be met and proposes mechanisms for addressing 134 them. 136 1.2. Requirements notation 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 2. Current State 144 This section describes the security mechanisms built into OSPFv2 and 145 OSPFv3. There are two goals to this section. First, this section 146 gives a brief explanation of the OSPF security mechanisms to those 147 familiar with connectionless integrity mechanisms but not with OSPF. 148 Second, this section explains the background necessary to understand 149 how OSPF fails to meet some of the requirements proposed for routing 150 security. 152 2.1. OSPFv2 154 Appendix D of [RFC2328] describes the basic procedure for 155 cryptographic authentication in OSPFv2. An authentication data field 156 in the OSPF packet header contains a key ID, the length of the 157 authentication data and a sequence number. A message authentication 158 code (MAC) is appended to the OSPF packet. This code protects all 159 fields of the packet including the sequence number but not the IP 160 header. 162 RFC 2328 defined the use of a keyed-MD5 MAC. While MD5 has not been 163 broken as a MAC, it is not the algorithm of choice for new MACs. 165 However, RFC 5709 [RFC5709] adds support for the SHA [FIPS180] family 166 of hashes to OSPFv2. The cryptographic authentication described in 167 RFC 5709 meets modern standards for per-packet integrity protection. 168 Thus, OSPFv2 meets the requirement for strong algorithms. Since 169 multiple algorithms are defined and a new algorithm can be selected 170 with each key, OSPFv2 meets the requirement for algorithm agility. 171 In order to provide cryptographic algorithms believed to have a 172 relatively long useful life, RFC 5709 mandates support for SHA-2 173 rather than SHA-1. 175 These security services provide integrity protection on each packet. 176 In addition, limited replay detection is provided. The sequence 177 number is non-decreasing. So, once a router has increased its 178 sequence number, an attacker cannot replay an old packet. 179 Unfortunately, sequence numbers are not required to increase for each 180 packet. For instance, because existing OSPF security solutions do 181 not specify how to set the sequence number, it is possible that some 182 implementations use, e.g., "seconds since reboot" as their sequence 183 numbers. The sequence numbers are thus only increased by every 184 second, permitting an opportunity for intra-connection replay. Also, 185 no mechanism is provided to deal with the loss of anti-replay state; 186 if sequence numbers are reused when a router reboots, then inter- 187 connection replays are straight forward. In 188 [I-D.ietf-ospf-security-extension-manual-keying], the OSPFv2 sequence 189 number is expanded to 64-bits with the least significant 32-bit value 190 containing a strictly increasing sequence number and the most 191 significant 32-bit value containing the boot count. The boot count 192 is retained in non-volatile storage for the deployment life of a OSPF 193 router. Therefore, the sequence number will never decrease even 194 after a cold reboot. 196 Also, because the IP header is not protected, the sequence number may 197 not be associated with the right neighbor; this opens up 198 opportunities for outsiders to perform replay attacks. See Section 3 199 for analysis of these attacks. In 200 [I-D.ietf-ospf-security-extension-manual-keying], this issue is 201 addressed by changing the definition of Apad from a constant defined 202 in [RFC5709] to the source address from the IP header of the OSPFv2 203 protocol packet. In this way, the source address from the IP header 204 is incorporated in the cryptographic authentication computation, and 205 any change of the IP source address will be detected. 207 The mechanism provides good support for key rollover. There is a key 208 ID; in addition mechanisms are described for managing key lifetimes 209 and starting the use of a new key in an orderly manner. Performing 210 orderly key rollover requires that implementations support accepting 211 a new key for received packets before using that key to generate 212 packets. Section D.3 of RFC 2328 requires this support in the form 213 of four configurable lifetimes for each key: two lifetimes control 214 the beginning and ending period for acceptance while two lifetimes 215 control the beginning and ending period for generation. This 216 provides a superset of the functionality in the key table 218 [I-D.ietf-karp-crypto-key-table] regarding lifetime. 220 The OSPFv2 replay mechanism does not handle prioritized transmission 221 of OSPF Hello and Link State Acknowledgement packets as recommended 222 in [RFC4222]. When OSPF packets are transmitted with varied 223 prioritization, they can arrive out-of-order resulting in packets 224 with lower prioritization being discarded. 226 2.2. OSPFv3 228 RFC 4552 describes how the IPsec authentication header and 229 encapsulating security payload mechanism can be used to protect 230 OSPFv3 packets. This mechanism provides per-packet integrity and 231 optional confidentiality using a wide variety of cryptographic 232 algorithms. Because OSPF uses multicast traffic, only manual key 233 management is supported. This mechanism meets requirements related 234 to algorithm selection and agility. 236 The Security Parameter Index (SPI) [RFC4301] provides an identifier 237 for the security association. This along with other IPsec facilities 238 provides a mechanism for moving from one key to another, meeting the 239 key rollover requirements. 241 Because manual keying is used, no replay protection is provided for 242 OSPFv3. Thus the intra-connection and inter-connection replay 243 requirements are not met. 245 There is another serious problem with the OSPFv3 security: rather 246 than being integrated into OSPF, it is based on IPsec. In practice, 247 this has lead to deployment problems. 249 OSPF implementations generally prioritize packets in order to 250 minimize disruption when router resources such as CPU or memory 251 experience contention. When IPsec is used with OSPFv3, the offset of 252 the packet type, which is used to prioritize packets, depends on what 253 integrity transform is used. For this reason, prioritizing packets 254 may be more complex for OSPFv3. One approach is to establish per-SPI 255 filters to find the packet type and act accordingly. 257 3. Impacts of OSPF Replays 259 As discussed, neither version of OSPF meets the requirements of 260 inter-connection or intra-connection replay protection. In order to 261 mount a replay, an attacker needs some mechanism to inject a packet; 262 physical security can limit a particular deployment's vulnerability 263 to replay attacks. This section discusses the impacts of OSPF 264 replays. 266 In OSPFv2, two facilities limit the scope of replay attacks. First, 267 when cryptographic authentication is used, each packet includes a 268 sequence number that is non-decreasing. In the current 269 specifications, the sequence number is remembered as part of an 270 adjacency: if an attacker can cause an adjacency to go down, then 271 replay state is lost. Database Description packets also include a 272 per-LSA sequence number that is part of the information that is 273 flooded. Even if a packet is replayed, the per-LSA sequence number 274 will prevent an old LSA from being installed. Unlike the per-packet 275 sequence number, the per-LSA sequence number must increase when an 276 LSA is changed. As a result, replays cannot be used to install old 277 routing information. 279 While the LSA sequence number provides some defense, the RPSEC 280 analysis [I-D.ietf-rpsec-ospf-vuln] describes a number of attacks 281 that are possible because of per-packet replays. The most serious 282 appear to be attacks against Hello packets, which may cause an 283 adjacency to fail. Other attacks may cause excessive flooding or 284 excessive use of CPU. 286 Another serious attack concerns Database Description packets. In 287 addition to the per-packet sequence number that is part of 288 cryptographic authentication for OSPFv2 and the per-LSA sequence 289 numbers, Database Description packets also include a Database 290 Description sequence number. If a Database Description packet with 291 the incorrect sequence number is received, then the database exchange 292 process will be restarted. 294 The per-packet OSPFv2 sequence number can be used to reduce the 295 window in which a replay is valid. A receiver will harmlessly reject 296 a packet whose per-packet sequence number is older than the one most 297 recently received from a neighbor. Replaying the most recent packet 298 from a neighbor does not appear to create problems. So, if the per- 299 packet sequence number is incremented on every packet sent, then 300 replay attacks should not disrupt OSPFv2. Unfortunately, OSPFv2 does 301 not have a procedure for dealing with sequence numbers reaching the 302 maximum value. It may be possible to figure out a set of rules 303 sufficient to disrupt the damage of packet replays while minimizing 304 the use of the sequence number space. 306 As mentioned previously, when an adjacency is dropped, replay state 307 is lost. So, after rebooting or when all adjacencies are lost, a 308 router may allow its sequence number to decrease. An attacker can 309 cause significant damage by replaying a packet captured before the 310 sequence number decrease at a time after the sequence number 311 decrease. If this happens, then the replayed packet will be accepted 312 and the sequence number will be updated. However, the legitimate 313 sender will be using a lower sequence number, so legitimate packets 314 will be rejected. A similar attack is possible in cases where OSPF 315 identifies a neighbor based on source address. An attacker can 316 change the source address of a captured packet and replay it. If the 317 attacker causes a replay from a neighbor with a high sequence number 318 to appear to be from a low sequence number neighbor, then 319 connectivity with that neighbor will be disrupted until the adjacency 320 fails. 322 OSPFv3 lacks the per-packet sequence number but has the per-LSA 323 sequence number. As such, OSPFv3 has no defense against denial of 324 service attacks that exploit replay. 326 4. Gap Analysis and Specific Requirements 328 The design guide requires each design team to enumerate a set of 329 requirements for the routing protocol. The only concerns identified 330 with OSPF are areas where it fails to meet general requirements 331 outlined in the threats and requirements document. This section 332 explains how some of these general requirements map specifically onto 333 the OSPF protocol and enumerates the specific gaps that need to be 334 addressed. 336 There is a general requirement for inter-connection replay 337 protection. In the context of OSPF, this means that if an adjacency 338 goes down between two neighbors and later is re-established, 339 replaying packets from before the adjacency went down cannot disrupt 340 the adjacency. In the context of OSPF, intra-connection replay 341 protection means that replaying a packet cannot prevent an adjacency 342 from forming or disrupt an adjacency. Meeting the requirements for 343 intra-connection and inter-connection replay protection is a 344 significant gap between the optimal state and where OSPF is today. 346 Since OSPF uses fields in the IP header, the general requirement to 347 protect the IP header and handle neighbor identification applies. 348 This is another gap that needs to be addressed. Because the replay 349 protection will depend on neighbor identification, the replay 350 protection cannot be adequately addressed without handling this issue 351 as well. 353 In order to encourage deployment of OSPFv3 security, an 354 authentication option is required that does not have the deployment 355 challenges of IPsec. 357 In order to support the requirement for simple preshared keys, OSPF 358 needs to make sure that when the same key is used for two different 359 purposes, no problems result. 361 In order to support packet prioritization, it is desirable for the 362 information needed to prioritize OSPF packets (the packet type) to be 363 at a constant location in the packet. 365 5. Solution Work 367 A security solution will be developed for OSPFv2 and OSPFv3 based on 368 the OSPFv2 cryptographic authentication option. This solution will 369 have the following improvements over the existing OSPFv2 option: 371 Address most inter-connection replay attacks by splitting the 372 sequence number and requiring preservation of state so that the 373 sequence number increases on every packet. 375 Add a form of simple key derivation so that if the same preshared 376 key is used for OSPF and other purposes, cross-protocol attacks do 377 not result 379 Support OSPFv3 authentication without use of IPsec 381 Specify processing rules sufficient to permit replay detection and 382 packet prioritization 384 Emphasize requirements already present in the OSPF specification 385 sufficient to permit key migration without disrupting adjacencies 387 Specify the proper use of the key table for OSPF 389 Protect the source IP address 391 Require that sequence numbers be incremented on each packet 393 The key components of this solution work are already underway. 394 OSPFv3 now supports an authentication option [RFC6506] that meets the 395 requirements of this section, except that it does not describe how 396 the key tables are used for OSPF. OSPFv2 is being enhanced 397 [I-D.ietf-ospf-security-extension-manual-keying] to protect the 398 source address, provide inter-connection replay and describe how to 399 use the key table. 401 6. IANA Considerations 403 This document makes no request of IANA. 405 7. Security Considerations 407 This memo discusses and compiles vulnerabilities in the existing OSPF 408 cryptographic handling. 410 In analyzing proposed improvements to OSPF per-packet security, it is 411 desirable to consider how these improvements interact with potential 412 improvements in overall routing security. For example, the impact of 413 replay attacks currently depends on the LSA sequence number 414 mechanism. If cryptographic protections against insider attackers 415 are considered by future work, then that work will need to provide a 416 solution that meets the needs of the per-packet replay defense as 417 well as protection of routing data from insider attack. An 418 experimental solution is discussed in [RFC2154] that explores end-to- 419 end protection of routing data in OSPF. It may be beneficial to 420 consider how improvements to the per-packet protections would 421 interact with such a mechanism to future-proof these mechanisms. 423 Implementations have a number of options in minimizing the potential 424 denial of service impact of OSPF cryptographic authentication. The 425 Generalized TTL Security Mechanism (GTSM) [RFC5082] might be 426 appropriate for OSPF packets other than those traversing virtual 427 links. Using this mechanism requires support of the sender; new OSPF 428 cryptographic authentication could specify this behavior if desired. 429 Alternatively implementations can limit the source addresses from 430 which they accept packets. Non-hello packets need only be accepted 431 from existing neighbors. If a system is under attack hello packets 432 from existing neighbors could be prioritized over hellos from new 433 neighbors. These mechanisms can be considered to limit the potential 434 impact of denial of service attacks on the cryptographic 435 authentication mechanism itself. 437 8. Acknowledgements 439 Funding for Sam Hartman's work on this memo is provided by Huawei. 441 The authors would like to thank Ran Atkinson, Michael Barnes, and 442 Manav Bhatia for valuable comments. 444 9. References 446 9.1. Normative References 448 [I-D.ietf-karp-threats-reqs] 449 Lebovitz, G. and M. Bhatia, "Keying and Authentication for 450 Routing Protocols (KARP) Overview, Threats, and 451 Requirements", draft-ietf-karp-threats-reqs-06 (work in 452 progress), September 2012. 454 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 455 Requirement Levels", BCP 14, RFC 2119, March 1997. 457 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 459 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 460 for OSPFv3", RFC 4552, June 2006. 462 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 463 Routing Protocols (KARP) Design Guidelines", RFC 6518, 464 February 2012. 466 9.2. Informative References 468 [FIPS180] US National Institute of Standards and Technology, "Secure 469 Hash Standard (SHS)", August 2002. 471 [I-D.ietf-karp-crypto-key-table] 472 Housley, R., Polk, T., Hartman, S., and D. Zhang, 473 "Database of Long-Lived Symmetric Cryptographic Keys", 474 draft-ietf-karp-crypto-key-table-04 (work in progress), 475 October 2012. 477 [I-D.ietf-karp-ops-model] 478 Hartman, S. and D. Zhang, "Operations Model for Router 479 Keying", draft-ietf-karp-ops-model-04 (work in progress), 480 October 2012. 482 [I-D.ietf-opsec-routing-protocols-crypto-issues] 483 Jaeggli, J., Hares, S., Bhatia, M., Manral, V., and R. 484 White, "Issues with existing Cryptographic Protection 485 Methods for Routing Protocols", 486 draft-ietf-opsec-routing-protocols-crypto-issues-07 (work 487 in progress), August 2010. 489 [I-D.ietf-ospf-security-extension-manual-keying] 490 Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, 491 "Security Extension for OSPFv2 when using Manual Key 492 Management", 493 draft-ietf-ospf-security-extension-manual-keying-03 (work 494 in progress), October 2012. 496 [I-D.ietf-rpsec-ospf-vuln] 497 Jones, E. and O. Moigne, "OSPF Security Vulnerabilities 498 Analysis", draft-ietf-rpsec-ospf-vuln-02 (work in 499 progress), June 2006. 501 [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with 502 Digital Signatures", RFC 2154, June 1997. 504 [RFC4222] Choudhury, G., "Prioritized Treatment of Specific OSPF 505 Version 2 Packets and Congestion Avoidance", BCP 112, 506 RFC 4222, October 2005. 508 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 509 Internet Protocol", RFC 4301, December 2005. 511 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 512 Pignataro, "The Generalized TTL Security Mechanism 513 (GTSM)", RFC 5082, October 2007. 515 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 516 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 517 Authentication", RFC 5709, October 2009. 519 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 520 with Existing Cryptographic Protection Methods for Routing 521 Protocols", RFC 6039, October 2010. 523 [RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting 524 Authentication Trailer for OSPFv3", RFC 6506, 525 February 2012. 527 Authors' Addresses 529 Sam Hartman 530 Painless Security 532 Email: hartmans-ietf@mit.edu 533 URI: http://www.painless-security.com/ 535 Dacheng Zhang 536 Huawei Technologies co. ltd 537 Huawei Building No.3 Xinxi Rd., Shang-Di Information Industrial Base Hai-Dian District, Beijing 538 China 540 Email: zhangdacheng@huawei.com