doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

diff --git a/doc/rfc/rfc7166.txt b/doc/rfc/rfc7166.txt
new file mode 100644
index 0000000..c899306
--- /dev/null
+++ b/doc/rfc/rfc7166.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+Bhatia, et al.               Standards Track                    [Page 1]
+
+RFC 7166            Authentication Trailer for OSPFv3         March 2014
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+Bhatia, et al.               Standards Track                    [Page 2]
+
+RFC 7166            Authentication Trailer for OSPFv3         March 2014
+
+
+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.
+
+
+
+
+
+Bhatia, et al.               Standards Track                    [Page 3]
+
+RFC 7166            Authentication Trailer for OSPFv3         March 2014
+
+
+   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.
+
+
+
+
+Bhatia, et al.               Standards Track                    [Page 4]
+
+RFC 7166            Authentication Trailer for OSPFv3         March 2014
+
+
+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
+
+
+
+Bhatia, et al.               Standards Track                    [Page 5]
+
+RFC 7166            Authentication Trailer for OSPFv3         March 2014
+
+
+   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
+
+
+
+Bhatia, et al.               Standards Track                    [Page 6]
+
+RFC 7166            Authentication Trailer for OSPFv3         March 2014
+
+
+   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.
+
+
+
+Bhatia, et al.               Standards Track                    [Page 7]
+
+RFC 7166            Authentication Trailer for OSPFv3         March 2014
+
+
+      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.
+
+
+
+
+
+Bhatia, et al.               Standards Track                    [Page 8]
+
+RFC 7166            Authentication Trailer for OSPFv3         March 2014
+
+
+      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.
+
+
+
+Bhatia, et al.               Standards Track                    [Page 9]
+
+RFC 7166            Authentication Trailer for OSPFv3         March 2014
+
+
+   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.
+
+
+
+
+
+
+
+
+
+Bhatia, et al.               Standards Track                   [Page 10]
+
+RFC 7166            Authentication Trailer for OSPFv3         March 2014
+
+
+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.
+
+
+
+
+
+
+
+
+Bhatia, et al.               Standards Track                   [Page 11]
+
+RFC 7166            Authentication Trailer for OSPFv3         March 2014
+
+
+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.
+
+
+
+Bhatia, et al.               Standards Track                   [Page 12]
+
+RFC 7166            Authentication Trailer for OSPFv3         March 2014
+
+
+   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)).
+
+
+
+
+
+
+Bhatia, et al.               Standards Track                   [Page 13]
+
+RFC 7166            Authentication Trailer for OSPFv3         March 2014
+
+
+      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.
+
+
+
+
+
+
+
+
+Bhatia, et al.               Standards Track                   [Page 14]
+
+RFC 7166            Authentication Trailer for OSPFv3         March 2014
+
+
+         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
+
+
+
+
+Bhatia, et al.               Standards Track                   [Page 15]
+
+RFC 7166            Authentication Trailer for OSPFv3         March 2014
+
+
+   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
+
+
+
+
+
+
+
+
+Bhatia, et al.               Standards Track                   [Page 16]
+
+RFC 7166            Authentication Trailer for OSPFv3         March 2014
+
+
+   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
+
+
+
+Bhatia, et al.               Standards Track                   [Page 17]
+
+RFC 7166            Authentication Trailer for OSPFv3         March 2014
+
+
+   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
+
+
+
+Bhatia, et al.               Standards Track                   [Page 18]
+
+RFC 7166            Authentication Trailer for OSPFv3         March 2014
+
+
+   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.
+
+
+
+
+
+
+
+Bhatia, et al.               Standards Track                   [Page 19]
+
+RFC 7166            Authentication Trailer for OSPFv3         March 2014
+
+
+   [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.
+
+
+
+
+
+
+
+
+
+Bhatia, et al.               Standards Track                   [Page 20]
+
+RFC 7166            Authentication Trailer for OSPFv3         March 2014
+
+
+   [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bhatia, et al.               Standards Track                   [Page 21]
+
+RFC 7166            Authentication Trailer for OSPFv3         March 2014
+
+
+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.
+
+
+
+Bhatia, et al.               Standards Track                   [Page 22]
+
+RFC 7166            Authentication Trailer for OSPFv3         March 2014
+
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bhatia, et al.               Standards Track                   [Page 23]
+