OSPF Working Group M. Bhatia Internet-Draft Alcatel-Lucent Intended status: Standards Track V. Manral Expires: February 23, 2012 Hewlett Packard A. Lindem Ericsson Aug 22, 2011 Supporting Authentication Trailer for OSPFv3 draft-ietf-ospf-auth-trailer-ospfv3-06 Abstract Currently OSPFv3 uses IPsec for authenticating protocol packets. However, there are some environments, e.g., Mobile Ad-hoc Networks (MANETs), where IPsec is difficult to configure and maintain, and this mechanism cannot be used. This draft proposes an alternative mechanism that can be used so that OSPFv3 does not depend upon IPsec for authentication. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 23, 2012. Copyright Notice Copyright (c) 2011 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 Bhatia, et al. Expires February 23, 2012 [Page 1] Internet-Draft Auth Trailer for OSPFv3 Aug 2011 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 Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Section . . . . . . . . . . . . . . . . . . . 4 2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 5 2.1. AT-Bit in Options Field . . . . . . . . . . . . . . . . . 5 2.2. Basic Operation . . . . . . . . . . . . . . . . . . . . . 6 2.3. IPv6 Source Address Protection . . . . . . . . . . . . . . 6 3. OSPFv3 Security Association . . . . . . . . . . . . . . . . . 7 4. Authentication Procedure . . . . . . . . . . . . . . . . . . . 9 4.1. Authentication Trailer . . . . . . . . . . . . . . . . . . 9 4.1.1. Sequence Number Wrap . . . . . . . . . . . . . . . . . 10 4.2. OSPFv3 Header Checksum . . . . . . . . . . . . . . . . . . 10 4.3. Cryptographic Authentication Procedure . . . . . . . . . . 11 4.4. Cryptographic Aspects . . . . . . . . . . . . . . . . . . 11 4.5. Message Verification . . . . . . . . . . . . . . . . . . . 13 5. Migration and Backward Compatibility . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Bhatia, et al. Expires February 23, 2012 [Page 2] Internet-Draft Auth Trailer for OSPFv3 Aug 2011 1. Introduction Unlike Open Shortest Path First version 2 (OSPFv2) [RFC2328], OSPF for IPv6 (OSPFv3) [RFC5340], does not include the AuType and Authentication fields in its headers for authenticating protocol packets. Instead, OSPFv3 relies on the IPv6 Authentication Header (AH)[RFC4302] and IPv6 Encapsulating Security Payload (ESP) [RFC4303] to provide integrity, authentication, and/or confidentiality. [RFC4552] describes how IPv6 AH and ESP extension headers can be used to provide authentication and/or confidentiality to OSPFv3. However, there are some environments, e.g., Mobile Ad-hoc Networks (MANETs), where IPsec is difficult to configure and maintain, and this mechanism cannot be used. There is also an issue with IPsec not being available on some platforms. [RFC4552] discusses, at length, the reasoning behind using manually configured keys, rather than some automated key management protocol such as IKEv2 [RFC5996]. The primary problem is the lack of suitable key management mechanism, as OSPFv3 adjacencies are formed on a one- to-many basis and most key management mechanisms are designed for a one-to-one communication model. This forces the system administrator to use manually configured security associations (SAs) and cryptographic keys to provide the authentication and, if desired, confidentiality services. Regarding replay protection [RFC4552] states that: "As it is not possible as per the current standards to provide complete replay protection while using manual keying, the proposed solution will not provide protection against replay attacks." Since there is no replay protection provided there are a number of vulnerabilities in OSPFv3 that have been discussed in [RFC6039]. Since there is no deterministic way to differentiate between encrypted and unencrypted ESP packets by simply examining the packet, it could become tricky for some implementations to prioritize certain OSPFv3 packets (Hellos for example) over the others. This draft proposes a new mechanism that works similar to OSPFv2 [RFC5709]for providing authentication to the OSPFv3 packets and attempts to solve the problems described above for OSPFv3. Additionally this document describes how HMAC-SHA authentication can be used for OSPFv3. Bhatia, et al. Expires February 23, 2012 [Page 3] Internet-Draft Auth Trailer for OSPFv3 Aug 2011 By definition, HMAC ([RFC2104] , [FIPS-198]) requires a cryptographic hash function. This document proposes to use any one of SHA-1, SHA- 256, SHA-384, or SHA-512 [FIPS-180-3] to authenticate the OSPFv3 packets. 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-3]. 1.1. Requirements Section 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 RFC2119 [RFC2119]. When used in lowercase, these words convey their typical use in common language, and are not to be interpreted as described in RFC2119 [RFC2119]. Bhatia, et al. Expires February 23, 2012 [Page 4] Internet-Draft Auth Trailer for OSPFv3 Aug 2011 2. Proposed Solution To perform non-IPsec cryptographic authentication, OSPFv3 routers append a special data block, henceforth referred to as, the authentication trailer to the end of the OSPFv3 packets. The length of the authentication trailer is not included into the length of the OSPFv3 packet, but is included in the IPv6 payload length. +---------------------+ -- -- +----------------------+ | IPv6 Header Length | ^ ^ | IPv6 Header Length | | HL = PL + LL | | | | HL = PL + LL + AL | | | v v | | +---------------------+ -- -- +----------------------+ | OSPFv3 Header | ^ ^ | OSPFv3 Header | | Length = PL | | | | Length = PL | | | | | | | |.....................| | Packet | |......................| | | | Length | | | | OSPFv3 Packet | | | | OSPFv3 Packet | | | v v | | +---------------------+ -- -- +----------------------+ | | ^ ^ | | | Optional LLS | | LLS Data | | Optional LLS | | LLS Block Len = LL | | Block | | LLS Block Len = LL | | | v Length v | | +---------------------+ -- -- +----------------------+ ^ | | AL = HL - (PL + LL) | | Authentication | | | AL = Fixed Trailer + | v | Digest Length | -- +----------------------+ Figure 1: Authentication Trailer in OSPFv3 The presence of the Link Local Signaling (LLS) [RFC5613] block, is determined by the L-bit setting in OSPFv3 options field in OSPFv3 Hello and Database Description packets. If present, the LLS block is included along with the OSPFv3 packet in the cryptographic authentication computation. 2.1. AT-Bit in Options Field A new AT-bit (AT stands for Authentication Trailer) is introduced into the OSPFv3 Options field. OSPFv3 routers MUST set the AT-bit in OSPFv3 Hello and Database Description packets to indicate that the OSPFv3 router will include the authentication trailer in all OSPFv3 packets on the link. For OSPFv3 Hello and Database Description packets, the AT-bit indicates the AT is present. For other OSPFv3 Bhatia, et al. Expires February 23, 2012 [Page 5] Internet-Draft Auth Trailer for OSPFv3 Aug 2011 packet types, the OSPFv3 AT bit setting is preserved from the OSPFv3 Hello/Database Description setting. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+ | | | | | | | | | | | | | |AT|L|AF|*|*|DC|R|N|MC|E|V6| +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+ Figure 2: OSPFv3 Options Field The AT-bit must be set in all OSPFv3 Hello and Database Description packets that contain an authentication trailer. 2.2. Basic Operation The procedure followed for computing the Authentication Trailer is much same as described in [RFC5709] and [RFC2328]. One difference is that the LLS block, if present, is included in the cryptographic authentication computation. The way the authentication data is carried in the Authentication Trailer is very similar to how it is done in case of [RFC2328]. The only difference between the OSPFv2 authentication trailer and the OSPFv3 authentication trailer is that information in addition to the message digest is included. The additional information in the OSPFv3 Authentication Trailer is included in the message digest computation and, therefore, protected by OSPFv3 cryptographic authentication as described herein. Consistent with OSPFv2 cryptographic authentication [RFC2328], both OSPFv3 header checksum calculation and verification are omitted when the OSPFv3 authentication mechanisms described in this specification are used. 2.3. IPv6 Source Address Protection While OSPFv3 always uses the Router ID to identify OSPFv3 neighbors, the IPv6 source address is learned from OSPFv3 hello packets and copied into the neighbor data structure [RFC5340]. Hence, OSPFv3 is susceptible to Man-in-the-Middle attacks where the IPv6 source address has been modified. To thwart such attacks, the IPv6 source address will be included in the message digest calculation and protected by OSPFv3 authentication. Refer to Section 4.4 for details. This is different than the procedure specified in [RFC5709] but consistent with [I-D.ietf-ospf-security-extension-manual-keying]. Bhatia, et al. Expires February 23, 2012 [Page 6] Internet-Draft Auth Trailer for OSPFv3 Aug 2011 3. OSPFv3 Security Association An OSPFv3 Security Association (SA) contains a set of parameters shared between any two legitimate OSPFv3 speakers. Parameters associated with an OSPFv3 SA: o Security Association Identifier (SA ID) This is a 32-bit unsigned integer used to uniquely identify an OSPFv3 SA, as manually configured by the network operator. The receiver determines the active SA by looking at the SA ID field in the incoming protocol packet. The sender, based on the active configuration, selects an SA to use and puts the correct Key ID value associated with the SA in the OSPFv3 protocol packet. If multiple valid and active OSPFv3 SAs exist for a given interface, the sender may use any of those SAs to protect the packet. Using SA IDs makes changing keys while maintaining protocol operation convenient. Each SA ID specifies two independent parts, the authentication protocol and the authentication key, as explained below. Normally, an implementation would allow the network operator to configure a set of keys in a key chain, with each key in the chain having fixed lifetime. The actual operation of these mechanisms is outside the scope of this document. Note that each SA ID can indicate a key with a different authentication protocol. This allows the introduction of new authentication mechanisms without disrupting existing OSPFv3 adjacencies. o Authentication Algorithm This signifies the authentication algorithm to be used with the OSPFv3 SA. This information is never sent in clear text over the wire. Because this information is not sent on the wire, the implementer chooses an implementation specific representation for this information. Currently, the following algorithms are supported: HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512. Bhatia, et al. Expires February 23, 2012 [Page 7] Internet-Draft Auth Trailer for OSPFv3 Aug 2011 o Authentication Key This value denotes the cryptographic authentication key associated with the OSPFv3 SA. The length of this key is variable and depends upon the authentication algorithm specified by the OSPFv3 SA. o Key Start Accept The time that this OSPFv3 router will accept packets that have been created with this OSPFv3 Security Association. o Key Start Generate The time that this OSPFv3 router will begin using this OSPFv3 Security Association for OSPFv3 packet generation. o Key Stop Generate The time that this OSPFv3 router will stop using this OSPFv3 Security Association for OSPFv3 packet generation. o Key Stop Accept The time that this OSPFv3 router will stop accepting packets generated with this OSPFv3 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 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 Bhatia, et al. Expires February 23, 2012 [Page 8] Internet-Draft Auth Trailer for OSPFv3 Aug 2011 4. Authentication Procedure 4.1. Authentication Trailer The authentication trailer that is appended to the OSPFv3 protocol packet is described below: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Type | Auth Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Association ID (SA ID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cryptographic Sequence Number (High Order 32 Bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cryptographic Sequence Number (Low Order 32 Bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authentication Data (Variable) | ~ ~ | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Authentication Trailer Format The various fields in the Authentication trailer are: o Auth Type 16-bit field identifying the type of authentication. The following values are defined in this specification: 0 - Reserved. 1 - Cryptographic Authentication as described herein. o Auth Data Len The length in octet of the Authentication Trailer (AT) including both the 16 octet fixed header and the variable length message digest. o Security Association Identifier (SA ID) 32-bit field that identifies the algorithm and the secret key used Bhatia, et al. Expires February 23, 2012 [Page 9] Internet-Draft Auth Trailer for OSPFv3 Aug 2011 to create the message digest appended to the OSPFv3 protocol packet. Security Association Identifiers are unique per- interface. o Cryptographic Sequence Number 64-bit strictly increasing sequence number that is used to guard against replay attacks. The 64-bit sequence number MUST be incremented for every OSPFv3 packet sent by the OSPFv3 router. Upon reception, the sequence number MUST be greater than the sequence number in the last OSPFv3 packet accepted from the sending OSPFv3 neighbor. Otherwise, the OSPFv3 packet is considered a replayed packet and dropped. OSPFv3 routers implementing this specification SHOULD use available mechanisms to preserve the sequence number's strictly increasing property for the deployed life of the OSPFv3 router (including cold restarts). One mechanism for accomplishing this would be to use the high order 32 bits of the sequence number as a wrap/boot count that is incremented anytime the OSPFv3 router loses its sequence number state. Sequence number wrap is described in Section 4.1.1. o Authentication Data Variable data that is carrying the digest for the protocol packet and optional LLS block. 4.1.1. Sequence Number Wrap When incrementing the sequence number for each transmitted OSPFv3 packet, the sequence number should be treated as an unsigned 64-bit value. If the lower order 32-bit value wraps, the high order 64-bit value should be saved in non-volatile storage. If by some chance the OSPFv3 router is deployed long enough that there is a possibility that the 64-bit sequence number may wrap, all keys, independent of key distribution mechanism, MUST be reset to avoid the possibility of replay attacks. Once the keys have been changes, the higher order sequence number can be reset to 0 and saved to non-volatile storage. 4.2. OSPFv3 Header Checksum Both OSPFv3 header checksum calculation and verification are omitted when the OSPFv3 authentication mechanisms described in this specification are used. This implies: o For OSPFv3 packets to be transmitted, the OSPFv3 header checksum computation is omitted and the OSPFv3 header checksum SHOULD be Bhatia, et al. Expires February 23, 2012 [Page 10] Internet-Draft Auth Trailer for OSPFv3 Aug 2011 set to 0 prior to computation of the OSPFv3 Authentication Trailer message digest. o For received OSPFv3 packets including an OSPFv3 Authentication Trailer, OSPFv3 header checksum verification MUST be omitted. 4.3. Cryptographic Authentication Procedure As noted earlier, the SA ID implicitly specifies the algorithms used to generate and verify the message digest. This specification discusses the computation of OSPFv3 Cryptographic Authentication data when any of the NIST SHS family of algorithms is used in the Hashed Message Authentication Code (HMAC) mode. The currently valid algorithms (including mode) for OSPFv3 Cryptographic Authentication include: HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 and HMAC-SHA-512 Of the above, implementations of this specification MUST include support for at least HMAC-SHA-1 and SHOULD include support for HMAC- SHA-256 and MAY also include support for HMAC-SHA-384 and HMAC-SHA- 512. 4.4. Cryptographic Aspects 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 OSPFv3 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 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. Bhatia, et al. Expires February 23, 2012 [Page 11] Internet-Draft Auth Trailer for OSPFv3 Aug 2011 Ipad is the hexadecimal value 0x36 repeated B times. Apad is a value which is the same length as the hash output or message digest. The first 16 octets contain the IPv6 source address followed by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. This implies that hash output is always a length of at least 16 octets. 1. Preparation of the 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 OSPFv3 packet's Authentication Data field in the Authentication Trailer (which is very similar to the appendage described in RFC 2328, Section D.4.3, Page 233, items(6)(a) and (6)(d)) is filled with the value Apad. Then, a First-Hash, also known as the inner hash, is computed as follows: First-Hash = H(Ko XOR Ipad || (OSPFv3 Packet)) Implementation Notes: Note that the First-Hash above includes the Authentication Trailer, as well as the OSPFv3 packet, as per RFC 2328, Section D.4.3 and, if present, the LLS block[RFC5613]. The definition of Apad (above) ensures it is always the same length as the hash output. This is consistent with RFC 2328. The "(OSPFv3 Packet)" mentioned in the First-Hash (above) does include both the optional LLS block and the OSPFv3 Authentication Trailer. The digest length for SHA-1 is 20 octets; for SHA-256, 32 octets; for SHA-384, 48 octets; and for SHA-512, 64 octets. Bhatia, et al. Expires February 23, 2012 [Page 12] Internet-Draft Auth Trailer for OSPFv3 Aug 2011 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) 4. Result The resulting Second-Hash becomes the authentication data that is sent in the Authentication Trailer of the OSPFv3 packet. The length of the authentication data 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 OSPFv3 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. Similar to this, the Authentication Trailer is not included in OSPFv3's own Length field, but is included in IPv6's payload length. 4.5. Message Verification A router would determine that OSPFv3 is using an Authentication trailer by examining the AT-bit in the Options field in the OSPFv3 header for Hello and Database Description packets. The specification in the Hello and Database description options indicates that other OSPFv3 packets will include the authentication trailer. The Authentication Trailer (AT) is accessed using the OSPFv3 packet header length to access the data after the OSPFv3 packet and, if an LLS Data Block [RFC5613] is present, using the LLS Data Block Length to access the data after the LLS Data Block. The L-bit in the OSPFv3 options in Hello and Database Description packets is examined to determine if an LLS Data Block is present. If an LLS block is present (as specified by the L-bit), it is included along with the OSPFv3 Hello or Database Description packet in the cryptographic authentication computation. Due to the placement of the AT following the LLS block and the fact that the LLS block is included in the cryptographic authentication Bhatia, et al. Expires February 23, 2012 [Page 13] Internet-Draft Auth Trailer for OSPFv3 Aug 2011 computation, OSPFv3 routers supporting this specification MUST minimally support examining the L-bit in the OSPFv3 options and using the length in the LLS block to access the AT. It is RECOMMENDED that OSPFv3 routers supporting this specification fully support OSPFv3 Link Local Signaling, [RFC5613]. If usage of the Authentication Trailer (AT), as specified herein, is configured for an OSPFv3 link, OSPFv3 Hello and Database Description packets with the AT-bit clear in the options will be dropped. All OSPFv3 packet types will be dropped if AT is configured for the link and the IPv6 header length is less than the amount necessary to include an authentication trailer. If the cryptographic sequence number in the AT is less than or equal to the last sequence number successfully received from the neighbor, the OSPFv3 packet MUST be dropped. Authentication algorithm dependent processing needs to be performed, using the algorithm specified by the appropriate OSPFv3 SA for the received packet. Before an implementation performs any processing it needs to save the values of the Authentication data field from the Authentication Trailer appended to the OSPFv3 packet. It should then set the Authentication Data field with Apad before the authentication data is computed. The calculated data is compared with the received authentication data in the Authentication trailer and the packet MUST be discarded if the two do not match. In such a case, an error event SHOULD be logged. Bhatia, et al. Expires February 23, 2012 [Page 14] Internet-Draft Auth Trailer for OSPFv3 Aug 2011 5. Migration and Backward Compatibility In general, all OSPFv3 routers participating on a link should be migrated to OSPFv3 Authentication at the same time. As with OSPFv2 authentication, a mismatch in the SA ID, Authentication Type, or message digest will result in failure to form an adjacency. For multi-access links, communities of OSPFv3 routers could be migrated using different interface instance IDs. However, at least one router would need to form adjacencies between both the OSPFv3 routers including and not including the authentication trailer. This would result in sub-optimal routing, as well as, added complexity and is only recommended in cases where authentication is desired on the link and it isn't feasible to migrate all the routers on the link at the same time. An implementation MAY have a transition mode where it includes the Authentication Trailer in the packets but does not verify this information. This is provided as a transition aid for networks in the process of migrating to the mechanism described in this draft. Bhatia, et al. Expires February 23, 2012 [Page 15] Internet-Draft Auth Trailer for OSPFv3 Aug 2011 6. Security Considerations The document proposes extensions to OSPFv3 that would make it more secure than [RFC5340]. It does not provide confidentiality as a routing protocol contains information that does not need to be kept secret. It does, however, provide means to authenticate the sender of the packets which is of interest to us. It should be noted that authentication method described in this document is not being used to authenticate the specific originator of a packet, but is rather being used to confirm that the packet has indeed been issued by a router which had access to the password. The mechanism described here is not perfect and does not need to be perfect. Instead, this mechanism represents a significant increase in the work function of an adversary attacking the OSPFv3 protocol, while not causing undue implementation, deployment, or operational complexity. Bhatia, et al. Expires February 23, 2012 [Page 16] Internet-Draft Auth Trailer for OSPFv3 Aug 2011 7. IANA Considerations IANA is requested to allocate AT-bit in the OSPFv3 "Options Registry" IANA is also requested to create new OSPFv3 "Authentication Trailer Types Registry" +-------------+----------------------+--------------------+ | Value/Range | Designation | Assignment Policy | +-------------+----------------------+--------------------+ | 0 | Reserved | Reserved | | | | | | 1 | Cryptographic | Already assigned | | | Authentication | | | | | | | 2-65535 | Unassigned | Standards Action | +-------------+----------------------+--------------------+ OSPFv3 Authentication Types Bhatia, et al. Expires February 23, 2012 [Page 17] Internet-Draft Auth Trailer for OSPFv3 Aug 2011 8. References 8.1. Normative References [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. [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, October 2009. 8.2. Informative References [FIPS-180-3] US National Institute of Standards & Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-3 , October 2008. [FIPS-198] US National Institute of Standards & Technology, "The Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 198 , March 2002. [I-D.ietf-ospf-security-extension-manual-keying] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, "Security Extension for OSPFv2 when using Manual Key Management", draft-ietf-ospf-security-extension-manual-keying-00 (work in progress), May 2011. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006. [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms Bhatia, et al. Expires February 23, 2012 [Page 18] Internet-Draft Auth Trailer for OSPFv3 Aug 2011 (SHA and HMAC-SHA)", RFC 4634, July 2006. [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009. [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues with Existing Cryptographic Protection Methods for Routing Protocols", RFC 6039, October 2010. Bhatia, et al. Expires February 23, 2012 [Page 19] Internet-Draft Auth Trailer for OSPFv3 Aug 2011 Appendix A. Acknowledgments First and foremost, thanks to the authors of RFC5709[RFC5709] from which this work was derived. Thanks to Sam Hartman for discussions on replay mitigation and the use of a 64-bit strictly increasing sequence number. Also, thanks to Sam for comments during IETF last call with respect to the OSPFv3 SA and sharing of key between protocols. Thanks to Michael Barnes for numerous comments and strong input on the coverage of LLS by the Authentication Trailer (AT). Thanks to Rajesh Shetty for numerous comments including the suggestion to include an Authentication Type field in the Authentication Trailer for extendibility. Thanks to Uma Chunduri for suggesting that we may want to protect the IPv6 source address even though OSPFv3 uses the Router ID for neighbor identification. Thanks to Srinivasan K L, Shraddha H, Alan Davey, and Glen Kent for their review comments. Thanks to Alan Davey, Russ White, Stan Ratliff, and others for their support of the draft. Also, thanks to Alan for WG last call comments. Thanks to Alia Atlas for comments made under the purview of the Routing Directorate review. The RFC text was produced using Marshall Rose's xml2rfc tool. Bhatia, et al. Expires February 23, 2012 [Page 20] Internet-Draft Auth Trailer for OSPFv3 Aug 2011 Authors' Addresses Manav Bhatia Alcatel-Lucent Bangalore, India Phone: Email: manav.bhatia@alcatel-lucent.com Vishwas Manral Hewlett Packard USA Phone: Email: vishwas.manral@hp.com Acee Lindem Ericsson 102 Carric Bend Court Cary, NC 27519 USA Phone: Email: acee.lindem@ericsson.com Bhatia, et al. Expires February 23, 2012 [Page 21]