diff options
Diffstat (limited to 'doc/rfc/rfc5709.txt')
| -rw-r--r-- | doc/rfc/rfc5709.txt | 787 |
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc5709.txt b/doc/rfc/rfc5709.txt new file mode 100644 index 0000000..7f635ee --- /dev/null +++ b/doc/rfc/rfc5709.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group M. Bhatia +Request for Comments: 5709 Alcatel-Lucent +Updates: 2328 V. Manral +Category: Standards Track IP Infusion + M. Fanto + Aegis Data Security + R. White + M. Barnes + Cisco Systems + T. Li + Ericsson + R. Atkinson + Extreme Networks + October 2009 + + OSPFv2 HMAC-SHA Cryptographic Authentication + +Abstract + + This document describes how the National Institute of Standards and + Technology (NIST) Secure Hash Standard family of algorithms can be + used with OSPF version 2's built-in, cryptographic authentication + mechanism. This updates, but does not supercede, the cryptographic + authentication mechanism specified in RFC 2328. + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright and License Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the BSD License. + + + + +Bhatia, et al. Standards Track [Page 1] + +RFC 5709 OSPFv2 HMAC-SHA October 2009 + + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +1. Introduction + + A variety of risks exist when deploying any routing protocol + [Bell89]. This document provides an update to OSPFv2 Cryptographic + Authentication, which is specified in Appendix D of RFC 2328. This + document does not deprecate or supercede RFC 2328. OSPFv2, itself, + is defined in RFC 2328 [RFC2328]. + + This document adds support for Secure Hash Algorithms (SHA) defined + in the US NIST Secure Hash Standard (SHS), which is defined by NIST + FIPS 180-2. [FIPS-180-2] includes SHA-1, SHA-224, SHA-256, SHA-384, + and SHA-512. The Hashed Message Authentication Code (HMAC) + authentication mode defined in NIST FIPS 198 is used [FIPS-198]. + + It is believed that [RFC2104] is mathematically identical to + [FIPS-198] and it is also believed that algorithms in [RFC4634] are + mathematically identical to [FIPS-180-2]. + + The creation of this addition to OSPFv2 was driven by operator + requests that they be able to use the NIST SHS family of algorithms + in the NIST HMAC mode, instead of being forced to use the Keyed-MD5 + algorithm and mode with OSPFv2 Cryptographic Authentication. + Cryptographic matters are discussed in more detail in the Security + Considerations section of this document. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +2. Background + + All OSPF protocol exchanges can be authenticated. The OSPF packet + header (see Appendix A.3.1 of RFC 2328) includes an Authentication + Type field and 64 bits of data for use by the appropriate + authentication scheme (determined by the Type field). + + + + +Bhatia, et al. Standards Track [Page 2] + +RFC 5709 OSPFv2 HMAC-SHA October 2009 + + + The authentication type is configurable on a per-interface (or, + equivalently, on a per-network/subnet) basis. Additional + authentication data is also configurable on a per-interface basis. + + OSPF authentication types 0, 1, and 2 are defined by RFC 2328. This + document provides an update to RFC 2328 that is only applicable to + Authentication Type 2, "Cryptographic Authentication". + +3. Cryptographic Authentication with NIST SHS in HMAC Mode + + Using this authentication type, a shared secret key is configured in + all routers attached to a common network/subnet. For each OSPF + protocol packet, the key is used to generate/verify a "message + digest" that is appended to the end of the OSPF packet. The message + digest is a one-way function of the OSPF protocol packet and the + secret key. Since the secret key is never sent over the network in + the clear, protection is provided against passive attacks [RFC1704]. + + The algorithms used to generate and verify the message digest are + specified implicitly by the secret key. This specification discusses + the computation of OSPFv2 Cryptographic Authentication data when any + of the NIST SHS family of algorithms is used in the Hashed Message + Authentication Code (HMAC) mode. Please also see RFC 2328, Appendix + D. + + With the additions in this document, the currently valid algorithms + (including mode) for OSPFv2 Cryptographic Authentication include: + + Keyed-MD5 (defined in RFC 2328, Appendix D) + HMAC-SHA-1 (defined here) + HMAC-SHA-256 (defined here) + HMAC-SHA-384 (defined here) + HMAC-SHA-512 (defined here) + + Of the above, implementations of this specification MUST include + support for at least: + + HMAC-SHA-256 + + and SHOULD include support for: + + HMAC-SHA-1 + + and SHOULD also (for backwards compatibility with existing + implementations and deployments) include support for: + + Keyed-MD5 + + + + +Bhatia, et al. Standards Track [Page 3] + +RFC 5709 OSPFv2 HMAC-SHA October 2009 + + + and MAY also include support for: + + HMAC-SHA-384 + HMAC-SHA-512 + + An implementation of this specification MUST allow network operators + to configure ANY authentication algorithm supported by that + implementation for use with ANY given KeyID value that is configured + into that OSPFv2 router. + +3.1. Generating Cryptographic Authentication + + The overall cryptographic authentication process defined in Appendix + D of RFC 2328 remains unchanged. However, the specific cryptographic + details (i.e., SHA rather than MD5, HMAC rather than Keyed-Hash) are + defined herein. To reduce the potential for confusion, this section + minimises the repetition of text from RFC 2328, Appendix D, which is + incorporated here by reference [RFC2328]. + + First, following the procedure defined in RFC 2328, Appendix D, + select the appropriate OSPFv2 Security Association for use with this + packet and set the KeyID field to the KeyID value of that OSPFv2 + Security Association. + + Second, set the Authentication Type to Cryptographic Authentication, + and set the Authentication Data Length field to the length (measured + in bytes, not bits) of the cryptographic hash that will be used. + When any NIST SHS algorithm is used in HMAC mode with OSPFv2 + Cryptographic Authentication, the Authentication Data Length is equal + to the normal hash output length (measured in bytes) for the specific + NIST SHS algorithm in use. For example, with NIST SHA-256, the + Authentication Data Length is 32 bytes. + + Third, the 32-bit cryptographic sequence number is set in accordance + with the procedures in RFC 2328, Appendix D that are applicable to + the Cryptographic Authentication type. + + Fourth, the message digest is then calculated and appended to the + OSPF packet, as described below in Section 3.3. The KeyID, + Authentication Algorithm, and Authentication Key to be used for + calculating the digest are all components of the selected OSPFv2 + Security Association. Input to the authentication algorithm consists + of the OSPF packet and the secret key. + + + + + + + + +Bhatia, et al. Standards Track [Page 4] + +RFC 5709 OSPFv2 HMAC-SHA October 2009 + + +3.2. OSPFv2 Security Association + + This document uses the term OSPFv2 Security Association (OSPFv2 SA) + to refer to the authentication key information defined in Section D.3 + of RFC 2328. The OSPFv2 protocol does not include an in-band + mechanism to create or manage OSPFv2 Security Associations. The + parameters of an OSPFv2 Security Association are updated to be: + + Key Identifier (KeyID) + This is an 8-bit unsigned value used to uniquely identify an + OSPFv2 SA and is configured either by the router administrator + (or, in the future, possibly by some key management protocol + specified by the IETF). The receiver uses this to locate the + appropriate OSPFv2 SA to use. The sender puts this KeyID value in + the OSPF packet based on the active OSPF configuration. + + Authentication Algorithm + This indicates the authentication algorithm (and also the + cryptographic mode, such as HMAC) to be used. This information + SHOULD never be sent over the wire in cleartext form. At present, + valid values are Keyed-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA- + 384, and HMAC-SHA-512. + + Authentication Key + This is the cryptographic key used for cryptographic + authentication with this OSPFv2 SA. This value SHOULD never be + sent over the wire in cleartext form. This is noted as "K" in + Section 3.3 below. + + Key Start Accept + The time that this OSPF router will accept packets that have been + created with this OSPF Security Association. + + Key Start Generate + The time that this OSPF router will begin using this OSPF Security + Association for OSPF packet generation. + + Key Stop Generate + The time that this OSPF router will stop using this OSPF Security + Association for OSPF packet generation. + + Key Stop Accept + The time that this OSPF router will stop accepting packets + generated with this OSPF Security Association. + + In order to achieve smooth key transition, KeyStartAccept SHOULD be + less than KeyStartGenerate and KeyStopGenerate SHOULD be less than + KeyStopAccept. If KeyStopGenerate and KeyStopAccept are left + + + +Bhatia, et al. Standards Track [Page 5] + +RFC 5709 OSPFv2 HMAC-SHA October 2009 + + + unspecified, the key's lifetime is infinite. When a new key replaces + an old, the KeyStartGenerate time for the new key MUST be less than + or equal to the KeyStopGenerate time of the old key. + + Key storage SHOULD persist across a system restart, warm or cold, to + avoid operational issues. In the event that the last key associated + with an interface expires, it is unacceptable to revert to an + unauthenticated condition, and not advisable to disrupt routing. + Therefore, the router should send a "last Authentication Key + expiration" notification to the network manager and treat the key as + having an infinite lifetime until the lifetime is extended, the key + is deleted by network management, or a new key is configured. + +3.3. Cryptographic Aspects + + This describes the computation of the Authentication Data value when + any NIST SHS algorithm is used in the HMAC mode with OSPFv2 + Cryptographic Authentication. + + In the algorithm description below, the following nomenclature, which + is consistent with [FIPS-198], is used: + + H is the specific hashing algorithm (e.g., SHA-256). + + K is the Authentication Key for the OSPFv2 security + association. + + Ko is the cryptographic key used with the hash algorithm. + + B is the block size of H, measured in octets + rather than bits. Note well that B is the + internal block size, not the hash size. + + For SHA-1 and SHA-256: B == 64 + For SHA-384 and SHA-512: B == 128 + + L is the length of the hash, measured in octets + rather than bits. + + XOR is the exclusive-or operation. + + Opad is the hexadecimal value 0x5c repeated B times. + + Ipad is the hexadecimal value 0x36 repeated B times. + + Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times. + + + + + +Bhatia, et al. Standards Track [Page 6] + +RFC 5709 OSPFv2 HMAC-SHA October 2009 + + + Implementation note: + This definition of Apad means that Apad is always the same + length as the hash output. + + (1) PREPARATION OF KEY + In this application, Ko is always L octets long. + + If the Authentication Key (K) is L octets long, then Ko is equal + to K. If the Authentication Key (K) is more than L octets long, + then Ko is set to H(K). If the Authentication Key (K) is less + than L octets long, then Ko is set to the Authentication Key (K) + with zeros appended to the end of the Authentication Key (K), + such that Ko is L octets long. + + (2) FIRST-HASH + First, the OSPFv2 packet's Authentication Trailer (which is the + appendage described in RFC 2328, Section D.4.3, Page 233, items + (6)(a) and (6)(d)) is filled with the value Apad, and the + Authentication Type field is set to 2. + + Then, a First-Hash, also known as the inner hash, is computed as + follows: + + First-Hash = H(Ko XOR Ipad || (OSPFv2 Packet)) + + Implementation Notes: + Note that the First-Hash above includes the Authentication + Trailer containing the Apad value, as well as the OSPF packet, + as per RFC 2328, Section D.4.3. + + The definition of Apad (above) ensures it is always the same + length as the hash output. This is consistent with RFC 2328. + The "(OSPFv2 Packet)" mentioned in the First-Hash (above) does + include the OSPF Authentication Trailer. + + The digest length for SHA-1 is 20 bytes; for SHA-256, 32 bytes; + for SHA-384, 48 bytes; and for SHA-512, 64 bytes. + + (3) SECOND-HASH + Then a Second-Hash, also known as the outer hash, is computed as + follows: + + Second-Hash = H(Ko XOR Opad || First-Hash) + + + + + + + + +Bhatia, et al. Standards Track [Page 7] + +RFC 5709 OSPFv2 HMAC-SHA October 2009 + + + (4) RESULT + The resulting Second-Hash becomes the Authentication Data that is + sent in the Authentication Trailer of the OSPFv2 packet. The + length of the Authentication Trailer is always identical to the + message digest size of the specific hash function H that is being + used. + + This also means that the use of hash functions with larger output + sizes will also increase the size of the OSPFv2 packet as + transmitted on the wire. + + Implementation Note: + RFC 2328, Appendix D specifies that the Authentication Trailer + is not counted in the OSPF packet's own Length field, but is + included in the packet's IP Length field. + +3.4. Message Verification + + Message verification follows the procedure defined in RFC 2328, + except that the cryptographic calculation of the message digest + follows the procedure in Section 3.3 above when any NIST SHS + algorithm in the HMAC mode is in use. Kindly recall that the + cryptographic algorithm/mode in use is indicated implicitly by the + KeyID of the received OSPFv2 packet. + + Implementation Notes: + One must save the received digest value before calculating the + expected digest value, so that after that calculation the received + value can be compared with the expected value to determine whether + to accept that OSPF packet. + + RFC 2328, Section D.4.3 (6) (c) should be read very closely prior + to implementing the above. With SHA algorithms in HMAC mode, Apad + is placed where the MD5 key would be put if Keyed-MD5 were in use. + +3.5. Changing OSPFv2 Security Associations + + Using KeyIDs makes changing the active OSPFv2 SA convenient. An + implementation can choose to associate a lifetime with each OSPFv2 SA + and can thus automatically switch to a different OSPFv2 SA based on + the lifetimes of the configured OSPFv2 SA(s). + + After changing the active OSPFv2 SA, the OSPF sender will use the + (different) KeyID value associated with the newly active OSPFv2 SA. + The receiver will use this new KeyID to select the appropriate (new) + OSPFv2 SA to use with the received OSPF packet containing the new + KeyID value. + + + + +Bhatia, et al. Standards Track [Page 8] + +RFC 5709 OSPFv2 HMAC-SHA October 2009 + + + Because the KeyID field is present, the receiver does not need to try + all configured OSPFv2 Security Associations with any received OSPFv2 + packet. This can mitigate some of the risks of a Denial-of-Service + (DoS) attack on the OSPF instance, but does not entirely prevent all + conceivable DoS attacks. For example, an on-link adversary still + could generate OSPFv2 packets that are syntactically valid but that + contain invalid Authentication Data, thereby forcing the receiver(s) + to perform expensive cryptographic computations to discover that the + packets are invalid. + +4. Security Considerations + + This document enhances the security of the OSPFv2 routing protocol by + adding, to the existing OSPFv2 Cryptographic Authentication method, + support for the algorithms defined in the NIST Secure Hash Standard + (SHS) using the Hashed Message Authentication Code (HMAC) mode, and + by adding support for the Hashed Message Authentication Code (HMAC) + mode. + + This provides several alternatives to the existing Keyed-MD5 + mechanism. There are published concerns about the overall strength + of the MD5 algorithm ([Dobb96a], [Dobb96b], [Wang04]). While those + published concerns apply to the use of MD5 in other modes (e.g., use + of MD5 X.509v3/PKIX digital certificates), they are not an attack + upon Keyed-MD5, which is what OSPFv2 specified in RFC 2328. There + are also published concerns about the SHA algorithm [Wang05] and also + concerns about the MD5 and SHA algorithms in the HMAC mode ([RR07], + [RR08]). Separately, some organisations (e.g., the US government) + prefer NIST algorithms, such as the SHA family, over other algorithms + for local policy reasons. + + The value Apad is used here primarily for consistency with IETF + specifications for HMAC-SHA authentication of RIPv2 SHA [RFC4822] and + IS-IS SHA [RFC5310] and to minimise OSPF protocol processing changes + in Section D.4.3 of RFC 2328 [RFC2328]. + + The quality of the security provided by the Cryptographic + Authentication option depends completely on the strength of the + cryptographic algorithm and cryptographic mode in use, the strength + of the key being used, and the correct implementation of the security + mechanism in all communicating OSPF implementations. Accordingly, + the use of high assurance development methods is recommended. It + also requires that all parties maintain the secrecy of the shared + secret key. [RFC4086] provides guidance on methods for generating + cryptographically random bits. + + + + + + +Bhatia, et al. Standards Track [Page 9] + +RFC 5709 OSPFv2 HMAC-SHA October 2009 + + + This mechanism is vulnerable to a replay attack by any on-link node. + An on-link node could record a legitimate OSPF packet sent on the + link, then replay that packet at the next time the recorded OSPF + packet's sequence number is valid. This replay attack could cause + significant routing disruptions within the OSPF domain. + + Ideally, for example, to prevent the preceding attack, each OSPF + Security Association would be replaced by a new and different OSPF + Security Association before any sequence number were reused. As of + the date this document was published, no form of automated key + management has been standardised for OSPF. So, as of the date this + document was published, common operational practice has been to use + the same OSPF Authentication Key for very long periods of time. This + operational practice is undesirable for many reasons. Therefore, it + is clearly desirable to develop and standardise some automated key- + management mechanism for OSPF. + + Because all of the currently specified algorithms use symmetric + cryptography, one cannot authenticate precisely which OSPF router + sent a given packet. However, one can authenticate that the sender + knew the OSPF Security Association (including the OSPFv2 SA's + parameters) currently in use. + + Because a routing protocol contains information that need not be kept + secret, privacy is not a requirement. However, authentication of the + messages within the protocol is of interest in order to reduce the + risk of an adversary compromising the routing system by deliberately + injecting false information into the routing system. + + The technology in this document enhances an authentication mechanism + for OSPFv2. The mechanism described here is not perfect and need not + be perfect. Instead, this mechanism represents a significant + increase in the work function of an adversary attacking OSPFv2, as + compared with plain-text authentication or null authentication, while + not causing undue implementation, deployment, or operational + complexity. Denial-of-Service attacks are not generally preventable + in a useful networking protocol [VK83]. + + Because of implementation considerations, including the need for + backwards compatibility, this specification uses the same mechanism + as specified in RFC 2328 and limits itself to adding support for + additional cryptographic hash functions. Also, some large network + operators have indicated they prefer to retain the basic mechanism + defined in RFC 2328, rather than migrate to IP Security, due to + deployment and operational considerations. If all the OSPFv2 routers + supported IPsec, then IPsec tunnels could be used in lieu of this + mechanism [RFC4301]. This would, however, relegate the topology to + point-to-point adjacencies over the mesh of IPsec tunnels. + + + +Bhatia, et al. Standards Track [Page 10] + +RFC 5709 OSPFv2 HMAC-SHA October 2009 + + + If a stronger authentication were believed to be required, then the + use of a full digital signature [RFC2154] would be an approach that + should be seriously considered. Use of full digital signatures would + enable precise authentication of the OSPF router originating each + OSPF link-state advertisement, and thereby provide much stronger + integrity protection for the OSPF routing domain. + +5. IANA Considerations + + The OSPF Authentication Codes registry entry for Cryptographic + Authentication (Registry Code 2) has been updated to refer to this + document as well as to RFC 2328. + +6. Acknowledgements + + The authors would like to thank Bill Burr, Tim Polk, John Kelsey, and + Morris Dworkin of (US) NIST for review of portions of this document + that are directly derived from the closely related work on RIPv2 + Cryptographic Authentication [RFC4822]. + + David Black, Nevil Brownlee, Acee Lindem, and Hilarie Orman (in + alphabetical order by last name) provided feedback on earlier + versions of this document. That feedback has greatly improved both + the technical content and the readability of the current document. + + Henrik Levkowetz's Internet Draft tools were very helpful in + preparing this document and are much appreciated. + +7. References + +7.1. Normative References + + [FIPS-180-2] US National Institute of Standards & Technology, "Secure + Hash Standard (SHS)", FIPS PUB 180-2, August 2002. + + [FIPS-198] US National Institute of Standards & Technology, "The + Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB + 198, March 2002. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. + + + + + + + + +Bhatia, et al. Standards Track [Page 11] + +RFC 5709 OSPFv2 HMAC-SHA October 2009 + + +7.2. Informative References + + [Bell89] Bellovin, S., "Security Problems in the TCP/IP Protocol + Suite", ACM Computer Communications Review, Volume 19, + Number 2, pp. 32-48, April 1989. + + [Dobb96a] Dobbertin, H, "Cryptanalysis of MD5 Compress", Technical + Report, 2 May 1996. (Presented at the Rump Session of + EuroCrypt 1996.) + + [Dobb96b] Dobbertin, H, "The Status of MD5 After a Recent Attack", + CryptoBytes, Vol. 2, No. 2, Summer 1996. + + [RFC1704] Haller, N. and R. Atkinson, "On Internet + Authentication", RFC 1704, October 1994. + + [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: + Keyed-Hashing for Message Authentication", RFC 2104, + February 1997. + + [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with + Digital Signatures", RFC 2154, June 1997. + + [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC + 4086, June 2005. + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + [RFC4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash + Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006. + + [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic + Authentication", RFC 4822, February 2007. + + [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., + and M. Fanto, "IS-IS Generic Cryptographic + Authentication", RFC 5310, February 2009. + + [RR07] Rechberger, C. and V. Rijmen, "On Authentication with + HMAC and Non-random Properties", Financial Cryptography + and Data Security, Lecture Notes in Computer Science, + Volume 4886/2008, Springer-Verlag, Berlin, December + 2007. + + + + + + +Bhatia, et al. Standards Track [Page 12] + +RFC 5709 OSPFv2 HMAC-SHA October 2009 + + + [RR08] Rechberger, C. and V. Rijmen, "New Results on NMAC/HMAC + when Instantiated with Popular Hash Functions", Journal + of Universal Computer Science, Volume 14, Number 3, pp. + 347-376, 1 February 2008. + + [VK83] Voydock, V. and S. Kent, "Security Mechanisms in High- + level Networks", ACM Computing Surveys, Vol. 15, No. 2, + June 1983. + + [Wang04] Wang, X., et alia, "Collisions for Hash Functions MD4, + MD5, HAVAL-128, and RIPEMD", August 2004, IACR, + http://eprint.iacr.org/2004/199 + + [Wang05] Wang, X., et alia, "Finding Collisions in the Full SHA- + 1" Proceedings of Crypto 2005, Lecture Notes in Computer + Science, Volume 3621, pp. 17-36, Springer-Verlag, + Berlin, August 31, 2005. + +Authors' Addresses + + Manav Bhatia + Alcatel-Lucent + Bangalore, + India + + EMail: manav.bhatia@alcatel-lucent.com + + + Vishwas Manral + IP Infusion + Almora, Uttarakhand + India + + EMail: vishwas@ipinfusion.com + + + Matthew J. Fanto + Aegis Data Security + Dearborn, MI + USA + + EMail: mfanto@aegisdatasecurity.com + + + + + + + + + +Bhatia, et al. Standards Track [Page 13] + +RFC 5709 OSPFv2 HMAC-SHA October 2009 + + + Russ I. White + Cisco Systems + 7025 Kit Creek Road + P.O. Box 14987 + RTP, NC + 27709 USA + + EMail: riw@cisco.com + + + M. Barnes + Cisco Systems + 225 West Tasman Drive + San Jose, CA + 95134 USA + + EMail: mjbarnes@cisco.com + + + Tony Li + Ericsson + 300 Holger Way + San Jose, CA + 95134 USA + + EMail: tony.li@tony.li + + + Randall J. Atkinson + Extreme Networks + 3585 Monroe Street + Santa Clara, CA + 95051 USA + + Phone: +1 (408) 579-2800 + EMail: rja@extremenetworks.com + + + + + + + + + + + + + + + +Bhatia, et al. Standards Track [Page 14] + |