OSPFv3 Auth Trailer: Supporting Authentication Trailer for OSPFv3

Internet Engineering Task Force (IETF)                         M. Bhatia
Request for Comments: 7166                                Alcatel-Lucent
Obsoletes: 6506                                                V. Manral
Category: Standards Track                                    Ionos Corp.
ISSN: 2070-1721                                                A. Lindem
                                                                Ericsson
                                                              March 2014


              Supporting Authentication Trailer for OSPFv3

Abstract

   Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism
   for authenticating protocol packets.  This behavior is different from
   authentication mechanisms present in other routing protocols (OSPFv2,
   Intermediate System to Intermediate System (IS-IS), RIP, and Routing
   Information Protocol Next Generation (RIPng)).  In some environments,
   it has been found that IPsec is difficult to configure and maintain
   and thus cannot be used.  This document defines an alternative
   mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does
   not depend only upon IPsec for authentication.

   The OSPFv3 Authentication Trailer was originally defined in RFC 6506.
   This document obsoletes RFC 6506 by providing a revised definition,
   including clarifications and refinements of the procedures.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7166.

Copyright Notice

   Copyright (c) 2014 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 Simplified BSD License.

Table of Contents

   1. Introduction ....................................................3
      1.1. Requirements ...............................................4
      1.2. Summary of Changes from RFC 6506 ...........................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 ...............................11
      4.2. OSPFv3 Header Checksum and LLS Data Block Checksum ........11
      4.3. Cryptographic Authentication Procedure ....................12
      4.4. Cross-Protocol Attack Mitigation ..........................12
      4.5. Cryptographic Aspects .....................................12
      4.6. Message Verification ......................................15
   5. Migration and Backward Compatibility ...........................16
   6. Security Considerations ........................................17
   7. IANA Considerations ............................................18
   8. References .....................................................19
      8.1. Normative References ......................................19
      8.2. Informative References ....................................19
   Appendix A. Acknowledgments .......................................22

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 IPsec protocols
   Authentication Header (AH) [RFC4302] and 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; this
   mechanism cannot be used in such environments.

   [RFC4552] discusses, at length, the reasoning behind using manually
   configured keys, rather than some automated key management protocol
   such as Internet Key Exchange version 2 (IKEv2) [RFC5996].  The
   primary problem is the lack of a 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:

      Since it is not possible using 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].

   While techniques exist to identify ESP-NULL packets [RFC5879], these
   techniques are generally not implemented in the data planes of OSPFv3
   routers.  This makes it very difficult for implementations to examine
   OSPFv3 packets and prioritize certain OSPFv3 packet types, e.g.,
   Hello packets, over the other types.

   This document defines a mechanism that works similarly to OSPFv2
   [RFC5709] to provide authentication to OSPFv3 packets and solves the
   problems related to replay protection and deterministically
   disambiguating different OSPFv3 packets as described above.

   This document adds support for the Secure Hash Algorithms (SHAs)
   defined in the US NIST Secure Hash Standard (SHS), which is specified
   by NIST FIPS 180-4.  [FIPS-180-4] 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-1 [FIPS-198-1] is used.

1.1.  Requirements

   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].

1.2.  Summary of Changes from RFC 6506

   This document includes the following changes from RFC 6506 [RFC6506]:

   1. Sections 2.2 and 4.2 explicitly state that the Link-Local
      Signaling (LLS) block checksum calculation is omitted when an
      OSPFv3 Authentication Trailer is used for OSPFv3 authentication.
      The LLS data block is included in the authentication digest
      calculation, and computation of a checksum is unnecessary.
      Clarification of this issue was documented in an erratum.

   2. Section 3 previously recommended usage of an expired key for
      transmitted OSPFv3 packets when no valid keys existed.  This
      statement has been removed.

   3. Section 4.5 includes a correction to the key preparation to use
      the Protocol-Specific Authentication Key (Ks) rather than the
      Authentication Key (K) as the initial key (Ko).  This problem was
      also documented in an erratum.

   4. Section 4.5 also includes a discussion of the choice of key length
      to be the hash length (L) rather than the block size (B).  The
      discussion of this choice was included to clarify an issue raised
      in a rejected erratum.

   5. Sections 4.1 and 4.6 indicate that sequence number checking is
      dependent on OSPFv3 packet type in order to account for packet
      prioritization as specified in [RFC4222].  This was an omission
      from RFC 6506 [RFC6506].

   6. Section 4.6 explicitly states that OSPFv3 packets with a
      nonexistent or expired Security Association (SA) will be dropped.

   7. Section 5 includes guidance on the precise actions required for an
      OSPFv3 router providing a backward-compatible transition mode.

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 in the length of the
   OSPFv3 packet but is included in the IPv6 payload length, as shown in
   Figure 1.

    +---------------------+ --              --  +----------------------+
    | IPv6 Payload Length | ^               ^   | IPv6 Payload Length  |
    | PL = OL + LL        | |               |   | PL = OL + LL + AL    |
    |                     | v               v   |                      |
    +---------------------+ --              --  +----------------------+
    | OSPFv3 Header       | ^               ^   | OSPFv3 Header        |
    | Length = OL         | |               |   | Length = OL          |
    |                     | |    OSPFv3     |   |                      |
    |.....................| |    Packet     |   |......................|
    |                     | |    Length     |   |                      |
    | OSPFv3 Packet       | |               |   | OSPFv3 Packet        |
    |                     | v               v   |                      |
    +---------------------+ --              --  +----------------------+
    |                     | ^               ^   |                      |
    | Optional LLS        | |    LLS Data   |   | Optional LLS         |
    | LL = LLS Data       | |    Block      |   | LL = LLS Data        |
    |      Block Length   | v    Length     v   |      Block Length    |
    +---------------------+ --              --  +----------------------+
                                            ^   |                      |
                       AL = PL - (OL + 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 the OSPFv3 Options field in OSPFv3
   Hello and Database Description packets.  If present, the LLS data
   block is included along with the OSPFv3 packet in the Cryptographic
   Authentication computation.

2.1.  AT-Bit in Options Field

   RFC 6506 introduced the AT-bit ("AT" stands for "Authentication
   Trailer") into the OSPFv3 Options field.  OSPFv3 routers MUST set the
   AT-bit in OSPFv3 Hello and Database Description packets to indicate
   that all the packets on this link will include an Authentication
   Trailer.  For OSPFv3 Hello and Database Description packets, the
   AT-bit indicates that the AT is present.  For other OSPFv3 packet
   types, the OSPFv3 AT-bit setting from the OSPFv3 Hello/Database
   Description setting is preserved in the OSPFv3 neighbor data
   structure.  OSPFv3 packet types that don't include an OSPFv3 Options
   field will use the setting from the neighbor data structure to
   determine whether or not the AT is expected.

            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, as shown in the figure above, 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 the same as those described in [RFC5709] and [RFC2328].  One
   difference is that the LLS data 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 the 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 is therefore protected by OSPFv3 Cryptographic Authentication as
   described herein.

   Consistent with OSPFv2 Cryptographic Authentication [RFC2328] and
   Link-Local Signaling Cryptographic Authentication [RFC5613], checksum
   calculation and verification are omitted for both the OSPFv3 header
   checksum and the LLS data block when the OSPFv3 authentication
   mechanism described in this specification is 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 is 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.5 for details.  This is
   different than the procedure specified in [RFC5709] but consistent
   with [MANUAL-KEY].

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 are as follows:

   o  Security Association Identifier (SA ID)

      This is a 16-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 algorithm 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 a 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 algorithm.  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 this
      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.

   o  Authentication Key

      This value denotes the Cryptographic Authentication Key associated
      with this OSPFv3 SA.  The length of this key is variable and
      depends upon the authentication algorithm specified by the
      OSPFv3 SA.

   o  KeyStartAccept

      This value indicates the time that this OSPFv3 router will accept
      packets that have been created with this OSPFv3 SA.

   o  KeyStartGenerate

      This value indicates the time that this OSPFv3 router will begin
      using this OSPFv3 SA for OSPFv3 packet generation.

   o  KeyStopGenerate

      This value indicates the time that this OSPFv3 router will stop
      using this OSPFv3 SA for OSPFv3 packet generation.

   o  KeyStopAccept

      This value indicates the time that this OSPFv3 router will stop
      accepting packets generated with this OSPFv3 SA.

      In order to achieve smooth key transition, KeyStartAccept SHOULD
      be less than KeyStartGenerate, and KeyStopGenerate SHOULD be less
      than KeyStopAccept.  If KeyStartGenerate or KeyStartAccept is left
      unspecified, the time will default to 0, and the key will be used
      immediately.  If KeyStopGenerate or KeyStopAccept is left
      unspecified, the time will default to infinity, and the key's
      lifetime will be infinite.  When a new key replaces an old key,
      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, the network operator SHOULD
      be notified, and the OSPFv3 packet MUST NOT be transmitted
      unauthenticated.

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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Authentication Type      |        Auth Data Len          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Reserved            |   Security Association 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 as follows:

   o  Authentication Type

      This 16-bit field identifies the type of authentication.  The
      following values are defined in this specification:

         0 - Reserved.
         1 - HMAC Cryptographic Authentication as described herein.

   o  Auth Data Len

      This is the length in octets of the Authentication Trailer (AT),
      including both the 16-octet fixed header and the variable-length
      message digest.

   o  Reserved

      This field is reserved.  It SHOULD be set to 0 when sending
      protocol packets and MUST be ignored when receiving protocol
      packets.

   o  Security Association Identifier (SA ID)

      This 16-bit field maps to the authentication algorithm and the
      secret key used to create the message digest appended to the
      OSPFv3 protocol packet.

      Though the SA ID implies the algorithm, the HMAC output size
      should not be used by implementers as an implicit hint, because
      additional algorithms may be defined in the future that have the
      same output size.

   o  Cryptographic Sequence Number

      This is a 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 accepted OSPFv3 packet of the same
      OSPFv3 packet type from the sending OSPFv3 neighbor.  Otherwise,
      the OSPFv3 packet is considered a replayed packet and dropped.
      OSPFv3 packets of different types may arrive out of order if they
      are prioritized as recommended in [RFC4222].

      OSPFv3 routers implementing this specification MUST 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

      This field contains variable data that is carrying the digest for
      the protocol packet and optional LLS data 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 higher-order
   32-bit value should be incremented and 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 their key distribution mechanism, MUST be reset
   to avoid the possibility of replay attacks.  Once the keys have been
   changed, the higher-order sequence number can be reset to 0 and saved
   to non-volatile storage.

4.2.  OSPFv3 Header Checksum and LLS Data Block Checksum

   Both the checksum calculation and verification are omitted for the
   OSPFv3 header checksum and the LLS data block checksum [RFC5613] when
   the OSPFv3 authentication mechanism described in this specification
   is used.  This implies the following:

   o  For OSPFv3 packets to be transmitted, the OSPFv3 header checksum
      computation is omitted, and the OSPFv3 header checksum SHOULD be
      set to 0 prior to computation of the OSPFv3 Authentication Trailer
      message digest.

   o  For OSPFv3 packets including an LLS data block to be transmitted,
      the OSPFv3 LLS data block checksum computation is omitted, and the
      OSPFv3 LLS data block checksum SHOULD be 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.
      However, if the OSPFv3 packet does include a non-zero OSPFv3
      header checksum, it will not be modified by the receiver and will
      simply be included in the OSPFv3 Authentication Trailer message
      digest verification.

   o  For received OSPFv3 packets including an LLS data block and OSPFv3
      Authentication Trailer, LLS data block checksum verification MUST
      be omitted.  However, if the OSPFv3 packet does include an LLS
      data block with a non-zero checksum, it will not be modified by
      the receiver and will simply be included in the OSPFv3
      Authentication Trailer message digest verification.

4.3.  Cryptographic Authentication Procedure

   As noted earlier, the SA ID maps to the authentication algorithm and
   the secret key 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:

   o  HMAC-SHA-1,

   o  HMAC-SHA-256,

   o  HMAC-SHA-384, and

   o  HMAC-SHA-512.

   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 MAY also include support for HMAC-SHA-384 and
   HMAC-SHA-512.

   Implementations of this specification MUST use HMAC-SHA-256 as the
   default authentication algorithm.

4.4.  Cross-Protocol Attack Mitigation

   In order to prevent cross-protocol replay attacks for protocols
   sharing common keys, the two-octet OSPFv3 Cryptographic Protocol ID
   is appended to the Authentication Key prior to use.  Other protocols
   using Cryptographic Authentication as specified herein MUST similarly
   append their respective Cryptographic Protocol IDs to their keys in
   this step.  Refer to the IANA Considerations (Section 7).

4.5.  Cryptographic Aspects

   In the algorithm description below, the following nomenclature, which
   is consistent with [FIPS-198-1], is used:

   H is the specific hashing algorithm (e.g., SHA-256).

   K is the Authentication Key from the OSPFv3 Security Association.

   Ks is a Protocol-Specific Authentication Key obtained by appending
   Authentication Key (K) with the two-octet OSPFv3 Cryptographic
   Protocol ID.

   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.

   Ipad is the hexadecimal value 0x36 repeated B times.

   Apad is a value that 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

      The OSPFv3 Cryptographic Protocol ID is appended to the
      Authentication Key (K), yielding a Protocol-Specific
      Authentication Key (Ks).  In this application, Ko is always
      L octets long.  While [RFC2104] supports a key that is up to
      B octets long, this application uses L as the Ks length consistent
      with [RFC4822], [RFC5310], and [RFC5709].  According to
      [FIPS-198-1], Section 3, keys greater than L octets do not
      significantly increase the function strength.  Ks is computed as
      follows:

         If Ks is L octets long, then Ko is equal to Ks.  If Ks is more
         than L octets long, then Ko is set to H(Ks).  If Ks is less
         than L octets long, then Ko is set to the value of Ks, with
         zeros appended to the end of Ks such that Ko is L octets long.

   2. First-Hash

      First, the OSPFv3 packet's Authentication Data field in the
      Authentication Trailer is filled with the value Apad.  This is
      very similar to the appendage described in [RFC2328],
      Appendix D.4.3, Items (6)(a) and (6)(d)).

      Then, a First-Hash, also known as the inner hash, is computed as
      follows:

         First-Hash = H(Ko XOR Ipad || (OSPFv3 Packet))

         When XORing Ko and Ipad, Ko will be padded with zeros to the
         length of Ipad.

         Implementation Note: The First-Hash above includes the
         Authentication Trailer as well as the OSPFv3 packet as per
         [RFC2328], Appendix D.4.3, and the LLS data block, if present
         [RFC5613].

      The definition of Apad (above) ensures that it is always the same
      length as the hash output.  This is consistent with RFC 2328.
      Note that the "(OSPFv3 Packet)" referenced in the First-Hash
      function above includes both the optional LLS data 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.

   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)

         When XORing Ko and Opad, Ko will be padded with zeros to the
         length of Opad.

   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: [RFC2328], 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
         the OSPFv3 header length but is included in the IPv6 header
         payload length.

4.6.  Message Verification

   A router would determine that OSPFv3 is using an Authentication
   Trailer (AT) 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 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 data 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 data block and the
   fact that the LLS data block is included in the Cryptographic
   Authentication computation, OSPFv3 routers supporting this
   specification MUST minimally support examining the L-bit in the
   OSPFv3 options and using the length in the LLS data 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 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 the AT is configured for the link and the IPv6 header
   length is less than the amount necessary to include an Authentication
   Trailer.

   The receiving interface's OSPFv3 SA is located using the SA ID in the
   received AT.  If the SA is not found, or if the SA is not valid for
   reception (i.e., current time < KeyStartAccept or
   current time >= KeyStopAccept), the OSPFv3 packet is dropped.

   If the cryptographic sequence number in the AT is less than or equal
   to the last sequence number in the last OSPFv3 packet of the same
   OSPFv3 type successfully received from the neighbor, the OSPFv3
   packet MUST be dropped, and an error event SHOULD be logged.  OSPFv3
   packets of different types may arrive out of order if they are
   prioritized as recommended in [RFC4222].

   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 (as described in Section 4.5).  The
   calculated data is compared with the received authentication data in
   the Authentication Trailer.  If the two do not match, the packet MUST
   be discarded, and an error event SHOULD be logged.

   After the OSPFv3 packet has been successfully authenticated,
   implementations MUST store the 64-bit cryptographic sequence number
   for each OSPFv3 packet type received from the neighbor.  The saved
   cryptographic sequence numbers will be used for replay checking for
   subsequent packets received from the neighbor.

5.  Migration and Backward Compatibility

   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
   migrating all the routers on the link at the same time isn't
   feasible.

   In support of uninterrupted deployment, an OSPFv3 router implementing
   this specification MAY implement a transition mode where it includes
   the Authentication Trailer in transmitted packets but does not verify
   this information in received packets.  This is provided as a
   transition aid for networks in the process of migrating to the
   authentication mechanism described in this specification.  More
   specifically:

   1. OSPFv3 routers in transition mode will include the OSPFv3
      Authentication Trailer in transmitted packets and set the AT-bit
      in the Options field of transmitted Hello and Database Description
      packets.  OSPFv3 routers receiving these packets and not having
      authentication configured will ignore the Authentication Trailer
      and AT-bit.

   2. OSPFv3 routers in transition mode will also calculate and set the
      OSPFv3 header checksum and the LLS data block checksum in
      transmitted packets so that they will not be dropped by OSPFv3
      routers without authentication configured.

   3. OSPFv3 routers in transition mode will authenticate received
      packets that either have the AT-bit set in the Options field for
      Hello or Database Description packets or are from a neighbor that
      previously set the AT-bit in the Options field of successfully
      authenticated Hello and Database Description packets.

   4. OSPFv3 routers in transition mode will also accept packets without
      the Options field AT-bit set in Hello and Database Description
      packets.  These packets will be assumed to be from OSPFv3 routers
      without authentication configured, and they will not be
      authenticated.  Additionally, the OSPFv3 header checksum and LLS
      data block checksum will be validated.

6.  Security Considerations

   This document proposes extensions to OSPFv3 that would make it more
   secure than OSPFv3 as defined in [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 packets that are of interest.  It
   addresses all the security issues that have been identified in
   [RFC6039] and [RFC6506].

   It should be noted that the authentication method described in this
   document is not being used to authenticate the specific originator of
   a packet but rather is being used to confirm that the packet has
   indeed been issued by a router that has access to the
   Authentication Key.

   Deployments SHOULD use sufficiently long and random values for the
   Authentication Key so that guessing and other cryptographic attacks
   on the key are not feasible in their environments.  Furthermore, it
   is RECOMMENDED that Authentication Keys incorporate at least 128
   pseudorandom bits to minimize the risk of such attacks.  In support
   of these recommendations, management systems SHOULD support
   hexadecimal input of Authentication Keys.

   Deployments that support a transitionary state but interoperate with
   routers that do not support this authentication method may be exposed
   to unauthenticated data during the transition period.

   The mechanism described herein is not perfect and does not need to be
   perfect.  Instead, this mechanism represents a significant increase
   in the effort required for an adversary to successfully attack the
   OSPFv3 protocol, while not causing undue implementation, deployment,
   or operational complexity.

   Refer to [RFC4552] for additional considerations on manual keying.

7.  IANA Considerations

   This document obsoletes RFC 6506; thus, IANA has updated the
   references in existing registries that pointed to RFC 6506 to point
   to this document.  This is the only IANA action requested by this
   document.

   IANA previously allocated the AT-bit (0x000400) in the "OSPFv3
   Options (24 bits)" registry as described in Section 2.1.

   IANA previously created the "Open Shortest Path First v3 (OSPFv3)
   Authentication Trailer Options" registry.  This registry includes the
   "OSPFv3 Authentication Types" registry, which defines valid values
   for the Authentication Type field in the OSPFv3 Authentication
   Trailer.  The registration procedure is Standards Action [RFC5226].

           +-------------+-----------------------------------+
           |Value        | Designation                       |
           +-------------+-----------------------------------+
           | 0           | Reserved                          |
           |             |                                   |
           | 1           | HMAC Cryptographic Authentication |
           |             |                                   |
           | 2-65535     | Unassigned                        |
           +-------------+-----------------------------------+

                        OSPFv3 Authentication Types

   Finally, IANA previously created the "Keying and Authentication for
   Routing Protocols (KARP) Parameters" registry.  This registry
   includes the "Cryptographic Protocol ID" registry, which provides
   unique protocol-specific values for cryptographic applications,
   including but not limited to prevention of cross-protocol replay
   attacks.  Values can be assigned for both native IPv4/IPv6 protocols
   and UDP/TCP protocols.  The registration procedure is Standards
   Action.

                  +-------------+----------------------+
                  | Value/Range | Designation          |
                  +-------------+----------------------+
                  | 0           | Reserved             |
                  |             |                      |
                  | 1           | OSPFv3               |
                  |             |                      |
                  | 2-65535     | Unassigned           |
                  +-------------+----------------------+

                         Cryptographic Protocol ID

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-4]
              US National Institute of Standards and Technology, "Secure
              Hash Standard (SHS)", FIPS PUB 180-4, March 2012.

   [FIPS-198-1]
              US National Institute of Standards and Technology, "The
              Keyed-Hash Message Authentication Code (HMAC)", FIPS
              PUB 198-1, July 2008.

   [MANUAL-KEY]
              Bhatia, M., Hartman, S., and D. Zhang, "Security Extension
              for OSPFv2 when using Manual Key Management", Work in
              Progress, February 2011.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

   [RFC4222]  Choudhury, G., Ed., "Prioritized Treatment of Specific
              OSPF Version 2 Packets and Congestion Avoidance", BCP 112,
              RFC 4222, October 2005.

   [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.

   [RFC4822]  Atkinson, R. and M. Fanto, "RIPv2 Cryptographic
              Authentication", RFC 4822, February 2007.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5310]  Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
              and M. Fanto, "IS-IS Generic Cryptographic
              Authentication", RFC 5310, February 2009.

   [RFC5613]  Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D.
              Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009.

   [RFC5879]  Kivinen, T. and D. McDonald, "Heuristics for Detecting
              ESP-NULL Packets", RFC 5879, May 2010.

   [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.

   [RFC6506]  Bhatia, M., Manral, V., and A. Lindem, "Supporting
              Authentication Trailer for OSPFv3", RFC 6506,
              February 2012.

Appendix A.  Acknowledgments

   First and foremost, thanks to the US National Institute of Standards
   and Technology for their work on the SHA [FIPS-180-4] and HMAC
   [FIPS-198-1].

   Thanks also need to go to the authors of the HMAC-SHA authentication
   RFCs, including [RFC4822], [RFC5310], and [RFC5709].  The basic
   HMAC-SHA procedures were originally described by Ran Atkinson in
   [RFC4822].

   Also, thanks to Ran Atkinson for help in the analysis of RFC 6506
   errata.

   Thanks to Srinivasan K L and Marek Karasek for their identification
   and submission of RFC 6506 errata.

   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 the sharing of keys between protocols.

   Thanks to Michael Barnes for numerous comments and strong input on
   the coverage of LLS by the Authentication Trailer (AT).

   Thanks to Marek Karasek for providing the specifics with respect to
   backward-compatible transition mode.

   Thanks to Michael Dubrovskiy and Anton Smirnov for comments on
   document revisions.

   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, Russ White, Stan
   Ratliff, and Glen Kent for their support and review comments.

   Thanks to Alia Atlas for comments made under the purview of the
   Routing Directorate review.

   Thanks to Stephen Farrell for comments during the IESG review.
   Stephen was also involved in the discussion of cross-protocol
   attacks.

   Thanks to Brian Carpenter for comments made during the Gen-ART
   review.

   Thanks to Victor Kuarsingh for the OPS-DIR review.

   Thanks to Brian Weis for the SEC-DIR review.

Authors' Addresses

   Manav Bhatia
   Alcatel-Lucent
   Bangalore
   India

   EMail: manav.bhatia@alcatel-lucent.com


   Vishwas Manral
   Ionos Corp.
   4100 Moorpark Ave.
   San Jose, CA  95117
   USA

   EMail: vishwas@ionosnetworks.com


   Acee Lindem
   Ericsson
   301 Midenhall Way
   Cary, NC  27513
   USA

   EMail: acee.lindem@ericsson.com