    Independent Submission                                       D. Ovsienko
    Request for Comments: 7298                                        Yandex
    Updates: 6126                                                  July 2014
    Category: Experimental
    ISSN: 2070-1721

                Babel Hashed Message Authentication Code (HMAC)
                          Cryptographic Authentication

    Abstract

       This document describes a cryptographic authentication mechanism for
       the Babel routing protocol.  This document updates RFC 6126.  The
       mechanism allocates two new TLV types for the authentication data,
       uses Hashed Message Authentication Code (HMAC), and is both optional
       and backward compatible.

    Status of This Memo

       This document is not an Internet Standards Track specification; it is
       published for examination, experimental implementation, and
       evaluation.

       This document defines an Experimental Protocol for the Internet
       community.  This is a contribution to the RFC Series, independently
       of any other RFC stream.  The RFC Editor has chosen to publish this
       document at its discretion and makes no statement about its value for
       implementation or deployment.  Documents approved for publication by
       the RFC Editor are not a candidate for any level of Internet
       Standard; see 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/rfc7298.

    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.

    Ovsienko                      Experimental                      [Page 1]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

    Table of Contents

       1. Introduction ....................................................3
          1.1. Requirements Language ......................................5
       2. Cryptographic Aspects ...........................................5
          2.1. Mandatory-to-Implement and Optional Hash Algorithms ........5
          2.2. Definition of Padding ......................................6
          2.3. Cryptographic Sequence Number Specifics ....................8
          2.4. Definition of HMAC .........................................9
       3. Updates to Protocol Data Structures ............................11
          3.1. RxAuthRequired ............................................11
          3.2. LocalTS ...................................................11
          3.3. LocalPC ...................................................11
          3.4. MaxDigestsIn ..............................................11
          3.5. MaxDigestsOut .............................................12
          3.6. ANM Table .................................................12
          3.7. ANM Timeout ...............................................13
          3.8. Configured Security Associations ..........................14
          3.9. Effective Security Associations ...........................16
       4. Updates to Protocol Encoding ...................................17
          4.1. Justification .............................................17
          4.2. TS/PC TLV .................................................19
          4.3. HMAC TLV ..................................................20
       5. Updates to Protocol Operation ..................................21
          5.1. Per-Interface TS/PC Number Updates ........................21
          5.2. Deriving ESAs from CSAs ...................................23
          5.3. Updates to Packet Sending .................................25
          5.4. Updates to Packet Receiving ...............................28
          5.5. Authentication-Specific Statistics Maintenance ............30
       6. Implementation Notes ...........................................31
          6.1. Source Address Selection for Sending ......................31
          6.2. Output Buffer Management ..................................31
          6.3. Optimizations of Deriving Procedure for ESAs ..............32
          6.4. Duplication of Security Associations ......................33
       7. Network Management Aspects .....................................34
          7.1. Backward Compatibility ....................................34
          7.2. Multi-Domain Authentication ...............................35
          7.3. Migration to and from Authenticated Exchange ..............36
          7.4. Handling of Authentication Key Exhaustion .................37
       8. Security Considerations ........................................38
       9. IANA Considerations ............................................43
       10. Acknowledgements ..............................................43
       11. References ....................................................44
          11.1. Normative References .....................................44
          11.2. Informative References ...................................44
       Appendix A. Figures and Tables ....................................47
       Appendix B. Test Vectors ..........................................52

    Ovsienko                      Experimental                      [Page 2]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

    1.  Introduction

       Authentication of routing protocol exchanges is a common means of
       securing computer networks.  The use of protocol authentication
       mechanisms helps in ascertaining that only the intended routers
       participate in routing information exchange and that the exchanged
       routing information is not modified by a third party.

       [BABEL] ("the original specification") defines data structures,
       encoding, and the operation of a basic Babel routing protocol
       instance ("instance of the original protocol").  This document ("this
       specification") defines data structures, encoding, and the operation
       of an extension to the Babel protocol -- an authentication mechanism
       ("this mechanism").  Both the instance of the original protocol and
       this mechanism are mostly self-contained and interact only at
       coupling points defined in this specification.

       A major design goal of this mechanism is transparency to operators
       that is not affected by implementation and configuration specifics.
       A complying implementation makes all meaningful details of
       authentication-specific processing clear to the operator, even when
       some of the operational parameters cannot be changed.

       The currently established (see [RIP2-AUTH], [OSPF2-AUTH],
       [ISIS-AUTH-A], [RFC6039], and [OSPF3-AUTH-BIS]) approach to an
       authentication mechanism design for datagram-based routing protocols
       such as Babel relies on two principal data items embedded into
       protocol packets, typically as two integral parts of a single data
       structure:

       o  A fixed-length unsigned integer, typically called a cryptographic
          sequence number, used in replay attack protection.

       o  A variable-length sequence of octets, a result of the Hashed
          Message Authentication Code (HMAC) construction (see [RFC2104])
          computed on meaningful data items of the packet (including the
          cryptographic sequence number) on one hand and a secret key on the
          other, used in proving that both the sender and the receiver share
          the same secret key and that the meaningful data was not changed
          in transmission.

       Depending on the design specifics, either all protocol packets or
       only those packets protecting the integrity of protocol exchange are
       authenticated.  This mechanism authenticates all protocol packets.

       Although the HMAC construction is just one of many possible
       approaches to cryptographic authentication of packets, this mechanism
       makes use of relevant prior experience by using HMAC as well, and its

    Ovsienko                      Experimental                      [Page 3]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       solution space correlates with the solution spaces of the mechanisms
       above.  At the same time, it allows for a future extension that
       treats HMAC as a particular case of a more generic mechanism.
       Practical experience with the mechanism defined herein should be
       useful in designing such a future extension.

       This specification defines the use of the cryptographic sequence
       number in detail sufficient to make replay attack protection strength
       predictable.  That is, an operator can tell the strength from the
       declared characteristics of an implementation and, if the
       implementation allows the changing of relevant parameters, the effect
       of a reconfiguration as well.

       This mechanism explicitly allows for multiple HMAC results per
       authenticated packet.  Since meaningful data items of a given packet
       remain the same, each such HMAC result stands for a different secret
       key and/or a different hash algorithm.  This enables a simultaneous,
       independent authentication within multiple domains.  This
       specification is not novel in this regard; for example, the Layer 2
       Tunneling Protocol (L2TPv3) allows for one or two results per
       authenticated packet ([RFC3931] Section 5.4.1), and Mobile Ad Hoc
       Network (MANET) protocols allow for several ([RFC7183] Section 6.1).

       An important concern addressed by this mechanism is limiting the
       amount of HMAC computations done per authenticated packet,
       independently for sending and receiving.  Without these limits, the
       number of computations per packet could be as high as the number of
       configured authentication keys (in the sending case) or as high as
       the number of keys multiplied by the number of supplied HMAC results
       (in the receiving case).

       These limits establish a basic competition between the configured
       keys and (in the receiving case) an additional competition between
       the supplied HMAC results.  This specification defines related data
       structures and procedures in a way to make such competition
       transparent and predictable for an operator.

       Wherever this specification mentions the operator reading or changing
       a particular data structure, variable, parameter, or event counter
       "at runtime", it is up to the implementor how this is to be done.
       For example, the implementation can employ an interactive command
       line interface (CLI), a management protocol such as the Simple
       Network Management Protocol (SNMP), a means of inter-process
       communication such as a local socket, or a combination of these.

    Ovsienko                      Experimental                      [Page 4]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

    1.1.  Requirements Language

       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 BCP 14 [RFC2119].

    2.  Cryptographic Aspects

    2.1.  Mandatory-to-Implement and Optional Hash Algorithms

       [RFC2104] defines HMAC as a construction that can use any
       cryptographic hash algorithm with a known digest length and internal
       block size.  This specification preserves this property of HMAC by
       defining data processing that itself does not depend on any
       particular hash algorithm either.  However, since this mechanism is a
       protocol extension case, there are relevant design considerations to
       take into account.

       Section 4.5 of [RFC6709] suggests selecting one hash algorithm as
       mandatory to implement for the purpose of global interoperability
       (Section 3.2 of [RFC6709]) and selecting another of distinct lineage
       as recommended for implementation for the purpose of cryptographic
       agility.  This specification makes the latter property guaranteed,
       rather than probable, through an elevation of the requirement level.
       There are two mandatory-to-implement hash algorithms; each is
       unambiguously defined and generally available in multiple
       implementations.

       An implementation of this mechanism MUST include support for two hash
       algorithms:

       o  RIPEMD-160 (160-bit digest)

       o  SHA-1 (160-bit digest)

       Besides that, an implementation of this mechanism MAY include support
       for additional hash algorithms, provided each such algorithm is
       publicly and openly specified and its digest length is 128 bits or
       more (to meet the constraint implied in Section 2.2).  Implementors
       SHOULD consider strong, well-known hash algorithms as additional
       implementation options and MUST NOT consider a hash algorithm if
       meaningful attacks exist for it or it is commonly viewed as
       deprecated.

    Ovsienko                      Experimental                      [Page 5]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       In the latter case, it is important to take into account
       considerations both common (such as those made in [RFC4270]) and
       specific to the HMAC application of the hash algorithm.  For example,
       [RFC6151] considers MD5 collisions and concludes that new protocol
       designs should not use HMAC-MD5, while [RFC6194] includes a
       comparable analysis of SHA-1 that finds HMAC-SHA-1 secure for the
       same purpose.

       For example, the following hash algorithms meet these requirements at
       the time of this writing (in alphabetical order):

       o  GOST R 34.11-94 (256-bit digest)

       o  SHA-224 (224-bit digest, SHA-2 family)

       o  SHA-256 (256-bit digest, SHA-2 family)

       o  SHA-384 (384-bit digest, SHA-2 family)

       o  SHA-512 (512-bit digest, SHA-2 family)

       o  Tiger (192-bit digest)

       o  Whirlpool (512-bit digest, 2nd rev., 2003)

       The set of hash algorithms available in an implementation MUST be
       clearly stated.  When known weak authentication keys exist for a hash
       algorithm used in the HMAC construction, an implementation MUST deny
       the use of such keys.

    2.2.  Definition of Padding

       Many practical applications of HMAC for authentication of datagram-
       based network protocols (including routing protocols) involve the
       padding procedure, a design-specific conditioning of the message that
       both the sender and the receiver perform before the HMAC computation.
       The specific padding procedure of this mechanism addresses the
       following needs:

       o  Data Initialization

          A design that places the HMAC result(s) computed for a message
          inside that same message after the computation has to have
          previously (i.e., before the computation) allocated in that
          message some data unit(s) purposed specifically for those HMAC

    Ovsienko                      Experimental                      [Page 6]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

          result(s) (in this mechanism, it is the HMAC TLV(s); see
          Section 4.3).  The padding procedure sets the respective octets of
          the data unit(s), in the simplest case to a fixed value known as
          the padding constant.

          The particular value of the constant is specific to each design.
          For instance, in [RIP2-AUTH] as well as works derived from it
          ([ISIS-AUTH-B], [OSPF2-AUTH], and [OSPF3-AUTH-BIS]), the value is
          0x878FE1F3.  In many other designs (for instance, [RFC3315],
          [RFC3931], [RFC4030], [RFC4302], [RFC5176], and [ISIS-AUTH-A]),
          the value is 0x00.

          However, the HMAC construction is defined on the basis of a
          cryptographic hash algorithm, that is, an algorithm meeting a
          particular set of requirements made for any input message.  Thus,
          any padding constant values, whether single- or multiple-octet, as
          well as any other message-conditioning methods, don't affect
          cryptographic characteristics of the hash algorithm and the HMAC
          construction, respectively.

       o  Source Address Protection

          In the specific case of datagram-based routing protocols, the
          protocol packet (that is, the message being authenticated) often
          does not include network-layer addresses, although the source and
          (to a lesser extent) the destination address of the datagram may
          be meaningful in the scope of the protocol instance.

          In Babel, the source address may be used as a prefix next hop (see
          Section 3.5.3 of [BABEL]).  A well-known (see Section 2.3 of
          [OSPF3-AUTH-BIS]) solution to the source address protection
          problem is to set the first respective octets of the data unit(s)
          above to the source address (yet setting the rest of the octets to
          the padding constant).  This procedure adapts this solution to the
          specifics of Babel, which allows for the exchange of protocol
          packets using both IPv4 and IPv6 datagrams (see Section 4 of
          [BABEL]).  Even though in the case of IPv6 exchange a Babel
          speaker currently uses only link-local source addresses
          (Section 3.1 of [BABEL]), this procedure protects all octets of an
          arbitrary given source address for the reasons of future
          extensibility.  The procedure implies that future Babel extensions
          will never use an IPv4-mapped IPv6 address as a packet source
          address.

    Ovsienko                      Experimental                      [Page 7]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

          This procedure does not protect the destination address, which is
          currently considered meaningless (Section 3.1 of [BABEL]) in the
          same scope.  A future extension that looks to add such protection
          would likely use a new TLV or sub-TLV to include the destination
          address in the protocol packet (see Section 4.1).

       Description of the padding procedure:

       1.  Set the first 16 octets of the Digest field of the given HMAC
           TLV to:

           *  the given source address, if it is an IPv6 address, or

           *  the IPv4-mapped IPv6 address (per Section 2.5.5.2 of
              [RFC4291]) holding the given source address, if it is an IPv4
              address.

       2.  Set the remaining (TLV Length - 18) octets of the Digest field of
           the given HMAC TLV to 0x00 each.

       For an example of a Babel packet with padded HMAC TLVs, see Table 3
       in Appendix A.

    2.3.  Cryptographic Sequence Number Specifics

       The operation of this mechanism may involve multiple local and
       multiple remote cryptographic sequence numbers, each essentially
       being a 48-bit unsigned integer.  This specification uses the term
       "TS/PC number" to avoid confusion with the route's (Section 2.5 of
       [BABEL]) or node's (Section 3.2.1 of [BABEL]) sequence numbers of the
       original Babel specification and to stress the fact that there are
       two distinguished parts of this 48-bit number, each handled in its
       specific way (see Section 5.1):

        0                   1     2 3                   4
        0 1 2 3 4 5 6 7 8 9 0 //  9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         TS         //         |              PC               |
       +-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          //

       The high-order 32 bits are called "timestamp" (TS), and the low-order
       16 bits are called "packet counter" (PC).

    Ovsienko                      Experimental                      [Page 8]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       This mechanism stores, updates, compares, and encodes each TS/PC
       number as two independent unsigned integers -- TS and PC,
       respectively.  Such a comparison of TS/PC numbers, as performed in
       item 3 of Section 5.4, is algebraically equivalent to a comparison of
       the respective 48-bit unsigned integers.  Any byte order conversion,
       when required, is performed on TS and PC parts independently.

    2.4.  Definition of HMAC

       The algorithm description below uses the following nomenclature,
       which is consistent with [FIPS-198]:

       Text   The data on which the HMAC is calculated (note item (b) of
              Section 8).  In this specification, it is the contents of a
              Babel packet ranging from the beginning of the Magic field of
              the Babel packet header to the end of the last octet of the
              Packet Body field, as defined in Section 4.2 of [BABEL] (see
              Figure 2 in Appendix A).

       H      The specific hash algorithm (see Section 2.1).

       K      A sequence of octets of an arbitrary, known length.

       Ko     The cryptographic key used with the hash algorithm.

       B      The block size of H, measured in octets rather than bits.
              Note that B is the internal block size, not the digest length.

       L      The digest length of H, measured in octets rather than bits.

       XOR    The bitwise exclusive-or operation.

       Opad   The hexadecimal value 0x5C repeated B times.

       Ipad   The hexadecimal value 0x36 repeated B times.

       The algorithm below is the original, unmodified HMAC construction as
       defined in both [RFC2104] and [FIPS-198]; hence, it is different from
       the algorithms defined in [RIP2-AUTH], [ISIS-AUTH-B], [OSPF2-AUTH],
       and [OSPF3-AUTH-BIS] in exactly two regards:

       o  The algorithm below sets the size of Ko to B, not to L (L is not
          greater than B).  This resolves both ambiguity in XOR expressions
          and incompatibility in the handling of keys that have length
          greater than L but not greater than B.

    Ovsienko                      Experimental                      [Page 9]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       o  The algorithm below does not change the value of Text before or
          after the computation.  Padding a Babel packet before the
          computation and placing the result inside the packet are both
          performed elsewhere.

       The intent of this is to enable the most straightforward use of
       cryptographic libraries by implementations of this specification.  At
       the time of this writing, implementations of the original HMAC
       construction coupled with hash algorithms of choice are generally
       available.

       Description of the algorithm:

       1.  Preparation of the Key

           In this application, Ko is always B octets long.  If K is B
           octets long, then Ko is set to K.  If K is more than B octets
           long, then Ko is set to H(K) with the necessary amount of zeroes
           appended to the end of H(K), such that Ko is B octets long.  If K
           is less than B octets long, then Ko is set to K with zeroes
           appended to the end of K, such that Ko is B octets long.

       2.  First-Hash

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

                        First-Hash = H(Ko XOR Ipad || Text)

       3.  Second-Hash

           A Second-Hash, also known as the outer hash, is computed
           as follows:

                     Second-Hash = H(Ko XOR Opad || First-Hash)

       4.  Result

           The resulting Second-Hash becomes the authentication data that is
           returned as the result of HMAC calculation.

       Note that in the case of Babel the Text parameter will never exceed a
       few thousand octets in length.  In this specific case, the
       optimization discussed in Section 6 of [FIPS-198] applies, namely,
       for a given K that is more than B octets long, the following
       associated intermediate results may be precomputed only once:
       Ko, (Ko XOR Ipad), and (Ko XOR Opad).

    Ovsienko                      Experimental                     [Page 10]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

    3.  Updates to Protocol Data Structures

    3.1.  RxAuthRequired

       RxAuthRequired is a boolean parameter.  Its default value MUST be
       TRUE.  An implementation SHOULD make RxAuthRequired a per-interface
       parameter but MAY make it specific to the whole protocol instance.
       The conceptual purpose of RxAuthRequired is to enable a smooth
       migration from an unauthenticated Babel packet exchange to an
       authenticated Babel packet exchange and back (see Section 7.3).  The
       current value of RxAuthRequired directly affects the receiving
       procedure defined in Section 5.4.  An implementation SHOULD allow the
       operator to change the RxAuthRequired value at runtime or by means of
       a Babel speaker restart.  An implementation MUST allow the operator
       to discover the effective value of RxAuthRequired at runtime or from
       the system documentation.

    3.2.  LocalTS

       LocalTS is a 32-bit unsigned integer variable.  It is the TS part of
       a per-interface TS/PC number.  LocalTS is a strictly per-interface
       variable not intended to be changed by the operator.  Its
       initialization is explained in Section 5.1.

    3.3.  LocalPC

       LocalPC is a 16-bit unsigned integer variable.  It is the PC part of
       a per-interface TS/PC number.  LocalPC is a strictly per-interface
       variable not intended to be changed by the operator.  Its
       initialization is explained in Section 5.1.

    3.4.  MaxDigestsIn

       MaxDigestsIn is an unsigned integer parameter conceptually purposed
       for limiting the amount of CPU time spent processing a received
       authenticated packet.  The receiving procedure performs the most
       CPU-intensive operation -- the HMAC computation -- only at most
       MaxDigestsIn (Section 5.4 item 7) times for a given packet.

       The MaxDigestsIn value MUST be at least 2.  An implementation SHOULD
       make MaxDigestsIn a per-interface parameter but MAY make it specific
       to the whole protocol instance.  An implementation SHOULD allow the
       operator to change the value of MaxDigestsIn at runtime or by means
       of a Babel speaker restart.  An implementation MUST allow the
       operator to discover the effective value of MaxDigestsIn at runtime
       or from the system documentation.

    Ovsienko                      Experimental                     [Page 11]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

    3.5.  MaxDigestsOut

       MaxDigestsOut is an unsigned integer parameter conceptually purposed
       for limiting the amount of a sent authenticated packet's space spent
       on authentication data.  The sending procedure adds at most
       MaxDigestsOut (Section 5.3 item 5) HMAC results to a given packet.

       The MaxDigestsOut value MUST be at least 2.  An implementation SHOULD
       make MaxDigestsOut a per-interface parameter but MAY make it specific
       to the whole protocol instance.  An implementation SHOULD allow the
       operator to change the value of MaxDigestsOut at runtime or by means
       of a Babel speaker restart, in a safe range.  The maximum safe value
       of MaxDigestsOut is implementation specific (see Section 6.2).  An
       implementation MUST allow the operator to discover the effective
       value of MaxDigestsOut at runtime or from the system documentation.

    3.6.  ANM Table

       The ANM (Authentic Neighbours Memory) table resembles the neighbour
       table defined in Section 3.2.3 of [BABEL].  Note that the term
       "neighbour table" means the neighbour table of the original Babel
       specification, and the term "ANM table" means the table defined
       herein.  Indexing of the ANM table is done in exactly the same way as
       indexing of the neighbour table, but its purpose, field set, and
       associated procedures are different.

       The conceptual purpose of the ANM table is to provide longer-term
       replay attack protection than would be possible using the neighbour
       table.  Expiry of an inactive entry in the neighbour table depends on
       the last received Hello Interval of the neighbour and typically
       stands for tens to hundreds of seconds (see Appendixes A and B of
       [BABEL]).  Expiry of an inactive entry in the ANM table depends only
       on the local speaker's configuration.  The ANM table retains (for at
       least the amount of seconds set by the ANM timeout parameter as
       defined in Section 3.7) a copy of the TS/PC number advertised in
       authentic packets by each remote Babel speaker.

    Ovsienko                      Experimental                     [Page 12]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       The ANM table is indexed by pairs of the form (Interface, Source).
       Every table entry consists of the following fields:

       o  Interface

          An implementation-specific reference to the local node's interface
          through which the authentic packet was received.

       o  Source

          The source address of the Babel speaker from which the authentic
          packet was received.

       o  LastTS

          A 32-bit unsigned integer -- the TS part of a remote TS/PC number.

       o  LastPC

          A 16-bit unsigned integer -- the PC part of a remote TS/PC number.

       Each ANM table entry has an associated aging timer, which is reset by
       the receiving procedure (Section 5.4 item 9).  If the timer expires,
       the entry is deleted from the ANM table.

       An implementation SHOULD use persistent memory (NVRAM) to retain the
       contents of the ANM table across restarts of the Babel speaker, but
       only as long as both the Interface field reference and expiry of the
       aging timer remain correct.  An implementation MUST be clear
       regarding if and how persistent memory is used for the ANM table.  An
       implementation SHOULD allow the operator to retrieve the current
       contents of the ANM table at runtime.  An implementation SHOULD allow
       the operator to remove some or all ANM table entries at runtime or by
       means of a Babel speaker restart.

    3.7.  ANM Timeout

       ANM timeout is an unsigned integer parameter.  An implementation
       SHOULD make ANM timeout a per-interface parameter but MAY make it
       specific to the whole protocol instance.  ANM timeout is conceptually
       purposed for limiting the maximum age (in seconds) of entries in the
       ANM table that stand for inactive Babel speakers.  The maximum age is
       immediately related to replay attack protection strength.  The
       strongest protection is achieved with the maximum possible value of
       ANM timeout set, but it may not provide the best overall result for
       specific network segments and implementations of this mechanism.

    Ovsienko                      Experimental                     [Page 13]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       Specifically, implementations unable to maintain the local TS/PC
       number strictly increasing across Babel speaker restarts will reuse
       the advertised TS/PC numbers after each restart (see Section 5.1).
       The neighbouring speakers will treat the new packets as replayed and
       discard them until the aging timer of the respective ANM table entry
       expires or the new TS/PC number exceeds the one stored in the entry.

       Another possible, but less probable, case could be an environment
       that uses IPv6 for the exchange of Babel datagrams and that involves
       physical moves of network-interface hardware between Babel speakers.
       Even when performed without restarting the speakers, these physical
       moves would cause random drops of the TS/PC number advertised for a
       given (Interface, Source) index, as viewed by neighbouring speakers,
       since IPv6 link-local addresses are typically derived from interface
       hardware addresses.

       Assuming that in such cases the operators would prefer to use a lower
       ANM timeout value to let the entries expire on their own rather than
       having to manually remove them from the ANM table each time, an
       implementation SHOULD set the default value of ANM timeout to a value
       between 30 and 300 seconds.

       At the same time, network segments may exist with every Babel speaker
       having its advertised TS/PC number strictly increasing over the
       deployed lifetime.  Assuming that in such cases the operators would
       prefer using a much higher ANM timeout value, an implementation
       SHOULD allow the operator to change the value of ANM timeout at
       runtime or by means of a Babel speaker restart.  An implementation
       MUST allow the operator to discover the effective value of ANM
       timeout at runtime or from the system documentation.

    3.8.  Configured Security Associations

       A Configured Security Association (CSA) is a data structure
       conceptually purposed for associating authentication keys and hash
       algorithms with Babel interfaces.  All CSAs are managed in finite
       sequences, one sequence per interface (hereafter referred to as
       "interface's sequence of CSAs").  Each interface's sequence of CSAs,
       as an integral part of the Babel speaker configuration, MAY be
       intended for persistent storage as long as this conforms with the
       implementation's key-management policy.  The default state of an
       interface's sequence of CSAs is empty, which has a special meaning of
       no authentication configured for the interface.  The sending
       (Section 5.3 item 1) and the receiving (Section 5.4 item 1)
       procedures address this convention accordingly.

    Ovsienko                      Experimental                     [Page 14]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       A single CSA structure consists of the following fields:

       o  HashAlgo

          An implementation-specific reference to one of the hash algorithms
          supported by this implementation (see Section 2.1).

       o  KeyChain

          A finite sequence of elements (hereafter referred to as "KeyChain
          sequence") representing authentication keys, each element being a
          structure consisting of the following fields:

          *  LocalKeyID

             An unsigned integer of an implementation-specific bit length.

          *  AuthKeyOctets

             A sequence of octets of an arbitrary, known length to be used
             as the authentication key.

          *  KeyStartAccept

             The time that this Babel speaker will begin considering this
             authentication key for accepting packets with authentication
             data.

          *  KeyStartGenerate

             The time that this Babel speaker will begin considering this
             authentication key for generating packet authentication data.

          *  KeyStopGenerate

             The time that this Babel speaker will stop considering this
             authentication key for generating packet authentication data.

          *  KeyStopAccept

             The time that this Babel speaker will stop considering this
             authentication key for accepting packets with authentication
             data.

       Since there is no limit imposed on the number of CSAs per interface,
       but the number of HMAC computations per sent/received packet is
       limited (through MaxDigestsOut and MaxDigestsIn, respectively), it
       may appear that only a fraction of the associated keys and hash

    Ovsienko                      Experimental                     [Page 15]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       algorithms are used in the process.  The ordering of elements within
       a sequence of CSAs and within a KeyChain sequence is important to
       make the association selection process deterministic and transparent.
       Once this ordering is deterministic at the Babel interface level, the
       intermediate data derived by the procedure defined in Section 5.2
       will be deterministically ordered as well.

       An implementation SHOULD allow an operator to set any arbitrary order
       of elements within a given interface's sequence of CSAs and within
       the KeyChain sequence of a given CSA.  Regardless of whether this
       requirement is or isn't met, the implementation MUST provide a means
       to discover the actual element order used.  Whichever order is used
       by an implementation, it MUST be preserved across Babel speaker
       restarts.

       Note that none of the CSA structure fields is constrained to contain
       unique values.  Section 6.4 explains this in more detail.  It is
       possible for the KeyChain sequence to be empty, although this is not
       the intended manner of using CSAs.

       The KeyChain sequence has a direct prototype, which is the "key
       chain" syntax item of some existing router configuration languages.
       If an implementation already implements this syntax item, it is
       suggested that the implementation reuse it, that is, implement a CSA
       syntax item that refers to a key chain item rather than reimplement
       the latter in full.

    3.9.  Effective Security Associations

       An Effective Security Association (ESA) is a data structure
       immediately used in sending (Section 5.3) and receiving (Section 5.4)
       procedures.  Its conceptual purpose is to determine a runtime
       interface between those procedures and the deriving procedure defined
       in Section 5.2.  All ESAs are temporary data units managed as
       elements of finite sequences that are not intended for persistent
       storage.  Element ordering within each such finite sequence
       (hereafter referred to as "sequence of ESAs") MUST be preserved as
       long as the sequence exists.

    Ovsienko                      Experimental                     [Page 16]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       A single ESA structure consists of the following fields:

       o  HashAlgo

          An implementation-specific reference to one of the hash algorithms
          supported by this implementation (see Section 2.1).

       o  KeyID

          A 16-bit unsigned integer.

       o  AuthKeyOctets

          A sequence of octets of an arbitrary, known length to be used as
          the authentication key.

       Note that among the protocol data structures introduced by this
       mechanism, the ESA structure is the only one not directly interfaced
       with the system operator (see Figure 1 in Appendix A); it is not
       immediately present in the protocol encoding, either.  However, the
       ESA structure is not just a possible implementation technique but an
       integral part of this specification: the deriving (Section 5.2), the
       sending (Section 5.3), and the receiving (Section 5.4) procedures are
       defined in terms of the ESA structure and its semantics provided
       herein.  The ESA structure is as meaningful for a correct
       implementation as the other protocol data structures.

    4.  Updates to Protocol Encoding

    4.1.  Justification

       The choice of encoding is very important in the long term.  The
       protocol encoding limits various authentication mechanism designs and
       encodings, which in turn limit future developments of the protocol.

       Considering existing implementations of the Babel protocol instance
       itself and related modules of packet analysers, the current encoding
       of Babel allows for compact and robust decoders.  At the same time,
       this encoding allows for future extensions of Babel by three (not
       excluding each other) principal means as defined in Sections 4.2 and
       4.3 of [BABEL] and further discussed in [BABEL-EXTENSION]:

       a.  A Babel packet consists of a four-octet header followed by a
           packet body, that is, a sequence of TLVs (see Figure 2 in
           Appendix A).  Besides the header and the body, an actual Babel

    Ovsienko                      Experimental                     [Page 17]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

           datagram may have an arbitrary amount of trailing data between
           the end of the packet body and the end of the datagram.  An
           instance of the original protocol silently ignores such trailing
           data.

       b.  The packet body uses a binary format allowing for 256 TLV types
           and imposing no requirements on TLV ordering or number of TLVs of
           a given type in a packet.  [BABEL] allocates TLV types 0 through
           10 (see Table 1 in Appendix A), defines the TLV body structure
           for each, and establishes the requirement for a Babel protocol
           instance to ignore any unknown TLV types silently.  This makes it
           possible to examine a packet body (to validate the framing and/or
           to pick particular TLVs for further processing), taking into
           account only the type (to distinguish between a Pad1 TLV and any
           other TLV) and the length of each TLV, regardless of whether any
           additional TLV types are eventually deployed (and if so, how
           many).

       c.  Within each TLV of the packet body, there may be some extra data
           after the expected length of the TLV body.  An instance of the
           original protocol silently ignores any such extra data.  Note
           that any TLV types without the expected length defined (such as
           the PadN TLV) cannot be extended with the extra data.

       Considering each of these three principal extension means for the
       specific purpose of adding authentication data items to each protocol
       packet, the following arguments can be made:

       o  The use of the TLV extra data of some existing TLV type would not
          be a solution, since no particular TLV type is guaranteed to be
          present in a Babel packet.

       o  The use of the TLV extra data could also conflict with future
          developments of the protocol encoding.

       o  Since the packet trailing data is currently unstructured, using it
          would involve defining an encoding structure and associated
          procedures; this would add to the complexity of both specification
          and implementation and would increase exposure to protocol attacks
          such as fuzzing.

       o  A naive use of the packet trailing data would make it unavailable
          to any future extension of Babel.  Since this mechanism is
          possibly not the last extension and since some other extensions
          may allow no other embedding means except the packet trailing
          data, the defined encoding structure would have to enable the
          multiplexing of data items belonging to different extensions.
          Such a definition is out of the scope of this work.

    Ovsienko                      Experimental                     [Page 18]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       o  Deprecating an extension (or only its protocol encoding) that uses
          purely purpose-allocated TLVs is as simple as deprecating the
          TLVs.

       o  The use of purpose-allocated TLVs is transparent for both the
          original protocol and any its future extensions, regardless of the
          embedding technique(s) used by the latter.

       Considering all of the above, this mechanism uses neither the packet
       trailing data nor the TLV extra data but uses two new TLV types:
       type 11 for a TS/PC number and type 12 for an HMAC result (see
       Table 1 in Appendix A).

    4.2.  TS/PC TLV

       The purpose of a TS/PC TLV is to store a single TS/PC number.  There
       is exactly one TS/PC TLV in an authenticated Babel packet.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 11   |     Length    |         PacketCounter         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Timestamp                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Fields:

       Type            Set to 11 to indicate a TS/PC TLV.

       Length          The length, in octets, of the body, exclusive of the
                       Type and Length fields.

       PacketCounter   A 16-bit unsigned integer in network byte order --
                       the PC part of a TS/PC number stored in this TLV.

       Timestamp       A 32-bit unsigned integer in network byte order --
                       the TS part of a TS/PC number stored in this TLV.

       Note that the ordering of PacketCounter and Timestamp in the TLV
       structure is the opposite of the ordering of TS and PC in the TS/PC
       number and the 48-bit equivalent (see Section 2.3).

       Considering the expected length and the extra data as mentioned in
       Section 4.3 of [BABEL], the expected length of a TS/PC TLV body is
       unambiguously defined as 6 octets.  The receiving procedure would
       correctly process any TS/PC TLV with body length not less than the
       expected length, ignoring any extra data (Section 5.4 items 3 and 9).

    Ovsienko                      Experimental                     [Page 19]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       The sending procedure produces a TS/PC TLV with body length equal to
       the expected length and the Length field, respectively, set as
       described in Section 5.3 item 3.

       Future Babel extensions (such as sub-TLVs) MAY modify the sending
       procedure to include the extra data after the fixed-size TS/PC TLV
       body defined herein, making adjustments to the Length TLV field, the
       "Body length" packet header field, and output buffer management (as
       explained in Section 6.2) necessary.

    4.3.  HMAC TLV

       The purpose of an HMAC TLV is to store a single HMAC result.  To
       assist a receiver in reproducing the HMAC computation, LocalKeyID
       modulo 2^16 of the authentication key is also provided in the TLV.
       There is at least one HMAC TLV in an authenticated Babel packet.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 12   |    Length     |             KeyID             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Digest...
       +-+-+-+-+-+-+-+-+-+-+-+-

       Fields:

       Type            Set to 12 to indicate an HMAC TLV.

       Length          The length, in octets, of the body, exclusive of the
                       Type and Length fields.

       KeyID           A 16-bit unsigned integer in network byte order.

       Digest          A variable-length sequence of octets that is at least
                       16 octets long (see Section 2.2).

       Considering the expected length and the extra data as mentioned in
       Section 4.3 of [BABEL], the expected length of an HMAC TLV body is
       not defined.  The receiving and padding procedures process every
       octet of the Digest field, deriving the field boundary from the
       Length field value (Section 5.4 item 7 and Section 2.2,
       respectively).  The sending procedure produces HMAC TLVs with the
       Length field precisely sizing the Digest field to match the digest
       length of the hash algorithm used (Section 5.3 items 5 and 8).

       The HMAC TLV structure defined herein is final.  Future Babel
       extensions MUST NOT extend it with any extra data.

    Ovsienko                      Experimental                     [Page 20]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

    5.  Updates to Protocol Operation

    5.1.  Per-Interface TS/PC Number Updates

       The LocalTS and LocalPC interface-specific variables constitute the
       TS/PC number of a Babel interface.  This number is advertised in the
       TS/PC TLV of authenticated Babel packets sent from that interface.
       There is only one property that is mandatory for the advertised TS/PC
       number: its 48-bit equivalent (see Section 2.3) MUST be strictly
       increasing within the scope of a given interface of a Babel speaker
       as long as the protocol instance is continuously operating.  This
       property, combined with ANM tables of neighbouring Babel speakers,
       provides them with the most basic replay attack protection.

       Initialization and increment are two principal updates performed on
       an interface TS/PC number.  The initialization is performed when a
       new interface becomes a part of a Babel protocol instance.  The
       increment is performed by the sending procedure (Section 5.3 item 2)
       before advertising the TS/PC number in a TS/PC TLV.

       Depending on the particular implementation method of these two
       updates, the advertised TS/PC number may possess additional
       properties that improve the replay attack protection strength.  This
       includes, but is not limited to, the methods below.

       a.  The most straightforward implementation would use LocalTS as a
           plain wrap counter, defining the updates as follows:

           initialization  Set LocalPC to 0, and set LocalTS to 0.

           increment       Increment LocalPC by 1.  If LocalPC wraps
                           (0xFFFF + 1 = 0x0000), increment LocalTS by 1.

           In this case, the advertised TS/PC numbers would be reused after
           each Babel protocol instance restart, making neighbouring
           speakers reject authenticated packets until the respective ANM
           table entries expire or the new TS/PC number exceeds the old (see
           Sections 3.6 and 3.7).

    Ovsienko                      Experimental                     [Page 21]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       b.  A more advanced implementation could make use of any 32-bit
           unsigned integer timestamp (number of time units since an
           arbitrary epoch), such as the UNIX timestamp, if the timestamp
           itself spans a reasonable time range and is guaranteed against a
           decrease (such as one resulting from network time use).  The
           updates would be defined as follows:

           initialization  Set LocalPC to 0, and set LocalTS to 0.

           increment       If the current timestamp is greater than LocalTS,
                           set LocalTS to the current timestamp and LocalPC
                           to 0, then consider the update complete.
                           Otherwise, increment LocalPC by 1, and if LocalPC
                           wraps, increment LocalTS by 1.

           In this case, the advertised TS/PC number would remain unique
           across the speaker's deployed lifetime without the need for any
           persistent storage.  However, a suitable timestamp source is not
           available in every implementation case.

       c.  Another advanced implementation could use LocalTS in a way
           similar to the "wrap/boot count" suggested in Section 4.1 of
           [OSPF3-AUTH-BIS], defining the updates as follows:

           initialization  Set LocalPC to 0.  If there is a TS value stored
                           in NVRAM for the current interface, set LocalTS
                           to the stored TS value, then increment the stored
                           TS value by 1.  Otherwise, set LocalTS to 0, and
                           set the stored TS value to 1.

           increment       Increment LocalPC by 1.  If LocalPC wraps, set
                           LocalTS to the TS value stored in NVRAM for the
                           current interface, then increment the stored TS
                           value by 1.

           In this case, the advertised TS/PC number would also remain
           unique across the speaker's deployed lifetime, relying on NVRAM
           for storing multiple TS numbers, one per interface.

       As long as the TS/PC number retains its mandatory property stated
       above, it is up to the implementor to determine which methods of TS/
       PC number updates are available and whether the operator can
       configure the method per interface and/or at runtime.  However, an
       implementation MUST disclose the essence of each update method it
       includes, in a comprehensible form such as natural language
       description, pseudocode, or source code.  An implementation MUST
       allow the operator to discover which update method is effective for
       any given interface, either at runtime or from the system

    Ovsienko                      Experimental                     [Page 22]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       documentation.  These requirements are necessary to enable the
       optimal (see Section 3.7) management of ANM timeout in a network
       segment.

       Note that wrapping (0xFFFFFFFF + 1 = 0x00000000) of LastTS is
       unlikely, but possible, causing the advertised TS/PC number to be
       reused.  Resolving this situation requires replacing all
       authentication keys of the involved interface.  In addition to that,
       if the wrap was caused by a timestamp reaching its end of epoch,
       using this mechanism will be impossible for the involved interface
       until some different timestamp or update implementation method is
       used.

    5.2.  Deriving ESAs from CSAs

       Neither receiving nor sending procedures work with the contents of an
       interface's sequence of CSAs directly; both (Section 5.4 item 4 and
       Section 5.3 item 4, respectively) derive a sequence of ESAs from the
       sequence of CSAs and use the derived sequence (see Figure 1 in
       Appendix A).  There are two main goals achieved through this
       indirection:

       o  Elimination of expired authentication keys and deduplication of
          security associations.  This is done as early as possible to keep
          subsequent procedures focused on their respective tasks.

       o  Maintenance of particular ordering within the derived sequence of
          ESAs.  The ordering deterministically depends on the ordering
          within the interface's sequence of CSAs and the ordering within
          the KeyChain sequence of each CSA.  The particular correlation
          maintained by this procedure implements a concept of fair
          (independent of the number of keys contained by each) competition
          between CSAs.

       The deriving procedure uses the following input arguments:

       o  input sequence of CSAs

       o  direction (sending or receiving)

       o  current time (CT)

    Ovsienko                      Experimental                     [Page 23]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       The processing of input arguments begins with an empty output
       sequence of ESAs and consists of the following steps:

       1.  Make a temporary copy of the input sequence of CSAs.

       2.  Remove all expired authentication keys from each KeyChain
           sequence of the copy, that is, any keys such that:

           *  for receiving: KeyStartAccept is greater than CT or
              KeyStopAccept is less than CT

           *  for sending: KeyStartGenerate is greater than CT or
              KeyStopGenerate is less than CT

           Note well that there are no special exceptions.  Remove all
           expired keys, even if there are no keys left after that (see
           Section 7.4).

       3.  Use the copy to populate the output sequence of ESAs as follows:

           3.1.  When the KeyChain sequence of the first CSA contains at
                 least one key, use its first key to produce an ESA with
                 fields set as follows:

                 HashAlgo       Set to HashAlgo of the current CSA.

                 KeyID          Set to LocalKeyID modulo 2^16 of the current
                                key of the current CSA.

                 AuthKeyOctets  Set to AuthKeyOctets of the current key of
                                the current CSA.

                 Append this ESA to the end of the output sequence.

           3.2.  When the KeyChain sequence of the second CSA contains at
                 least one key, use its first key the same way, and so forth
                 until all first keys of the copy are processed.

           3.3.  When the KeyChain sequence of the first CSA contains at
                 least two keys, use its second key the same way.

           3.4.  When the KeyChain sequence of the second CSA contains at
                 least two keys, use its second key the same way, and so
                 forth until all second keys of the copy are processed.

           3.5.  ...and so forth, until all keys of all CSAs of the copy are
                 processed, exactly once each.

    Ovsienko                      Experimental                     [Page 24]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

           In the description above, the ordinals ("first", "second", and so
           on) with regard to keys stand for an element position after the
           removal of expired keys, not before.  For example, if a KeyChain
           sequence was { Ka, Kb, Kc, Kd } before the removal and became
           { Ka, Kd } after, then Ka would be the "first" element and Kd
           would be the "second".

       4.  Deduplicate the ESAs in the output sequence; that is, wherever
           two or more ESAs exist that share the same (HashAlgo, KeyID,
           AuthKeyOctets) triplet value, remove all of these ESAs except the
           one closest to the beginning of the sequence.

       The resulting sequence will contain zero or more unique ESAs, ordered
       in a way deterministically correlated with the ordering of CSAs
       within the original input sequence of CSAs and the ordering of keys
       within each KeyChain sequence.  This ordering maximizes the
       probability of having an equal amount of keys per original CSA in any
       N first elements of the resulting sequence.  Possible optimizations
       of this deriving procedure are outlined in Section 6.3.

    5.3.  Updates to Packet Sending

       Perform the following authentication-specific processing after the
       instance of the original protocol considers an outgoing Babel packet
       ready for sending, but before the packet is actually sent (see
       Figure 1 in Appendix A).  After that, send the packet, regardless of
       whether the authentication-specific processing modified the outgoing
       packet or left it intact.

       1.  If the current outgoing interface's sequence of CSAs is empty,
           finish authentication-specific processing and consider the packet
           ready for sending.

       2.  Increment the TS/PC number of the current outgoing interface, as
           explained in Section 5.1.

       3.  Add to the packet body (see the note at the end of this section)
           a TS/PC TLV with fields set as follows:

           Type            Set to 11.

           Length          Set to 6.

           PacketCounter   Set to the current value of the LocalPC variable
                           of the current outgoing interface.

    Ovsienko                      Experimental                     [Page 25]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

           Timestamp       Set to the current value of the LocalTS variable
                           of the current outgoing interface.

           Note that the current step may involve byte order conversion.

       4.  Derive a sequence of ESAs, using the procedure defined in
           Section 5.2, with the current interface's sequence of CSAs as the
           input sequence of CSAs, the current time as CT, and "sending" as
           the direction.  Proceed to the next step even if the derived
           sequence is empty.

       5.  Iterate over the derived sequence, using its ordering.  For each
           ESA, add to the packet body (see the note at the end of this
           section) an HMAC TLV with fields set as follows:

           Type     Set to 12.

           Length   Set to 2 plus the digest length of HashAlgo of the
                    current ESA.

           KeyID    Set to KeyID of the current ESA.

           Digest   Size exactly equal to the digest length of HashAlgo of
                    the current ESA.  Pad (see Section 2.2), using the
                    source address of the current packet (see Section 6.1).

           As soon as there are MaxDigestsOut HMAC TLVs added to the current
           packet body, immediately proceed to the next step.

           Note that the current step may involve byte order conversion.

       6.  Increment the "Body length" field value of the current packet
           header by the total length of TS/PC and HMAC TLVs appended to the
           current packet body so far.

           Note that the current step may involve byte order conversion.

       7.  Make a temporary copy of the current packet.

    Ovsienko                      Experimental                     [Page 26]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       8.  Iterate over the derived sequence again, using the same order and
           number of elements.  For each ESA (and, respectively, for each
           HMAC TLV recently appended to the current packet body), compute
           an HMAC result (see Section 2.4), using the temporary copy (not
           the original packet) as Text, HashAlgo of the current ESA as H,
           and AuthKeyOctets of the current ESA as K.  Write the HMAC result
           to the Digest field of the current HMAC TLV (see Table 4 in
           Appendix A) of the current packet (not the copy).

       9.  After this point, allow no more changes to the current packet
           header and body, and consider it ready for sending.

       Note that even when the derived sequence of ESAs is empty, the packet
       is sent anyway, with only a TS/PC TLV appended to its body.  Although
       such a packet would not be authenticated, the presence of the sole
       TS/PC TLV would indicate authentication key exhaustion to operators
       of neighbouring Babel speakers.  See also Section 7.4.

       Also note that it is possible to place the authentication-specific
       TLVs in the packet's sequence of TLVs in a number of different valid
       ways so long as there is exactly one TS/PC TLV in the sequence and
       the ordering of HMAC TLVs relative to each other, as produced in
       step 5 above, is preserved.

       For example, see Figure 2 in Appendix A.  The diagrams represent a
       Babel packet without (D1) and with (D2, D3, D4) authentication-
       specific TLVs.  The optional trailing data block that is present in
       D1 is preserved in D2, D3, and D4.  Indexing (1, 2, ..., n) of the
       HMAC TLVs means the order in which the sending procedure produced
       them (and, respectively, the HMAC results).  In D2, the added TLVs
       are appended: the previously existing TLVs are followed by the TS/PC
       TLV, which is followed by the HMAC TLVs.  In D3, the added TLVs are
       prepended: the TS/PC TLV is the first and is followed by the HMAC
       TLVs, which are followed by the previously existing TLVs.  In D4, the
       added TLVs are intermixed with the previously existing TLVs and the
       TS/PC TLV is placed after the HMAC TLVs.  All three packets meet the
       requirements above.

       Implementors SHOULD use appending (D2) for adding the authentication-
       specific TLVs to the sequence; this is expected to result in more
       straightforward implementation and troubleshooting in most use cases.

    Ovsienko                      Experimental                     [Page 27]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

    5.4.  Updates to Packet Receiving

       Perform the following authentication-specific processing after an
       incoming Babel packet is received from the local network stack but
       before it is acted upon by the Babel protocol instance (see Figure 1
       in Appendix A).  The final action conceptually depends not only upon
       the result of the authentication-specific processing but also on the
       current value of the RxAuthRequired parameter.  Immediately after any
       processing step below accepts or refuses the packet, either deliver
       the packet to the instance of the original protocol (when the packet
       is accepted or RxAuthRequired is FALSE) or discard it (when the
       packet is refused and RxAuthRequired is TRUE).

       1.   If the current incoming interface's sequence of CSAs is empty,
            accept the packet.

       2.   If the current packet does not contain exactly one TS/PC TLV,
            refuse it.

       3.   Perform a lookup in the ANM table for an entry having Interface
            equal to the current incoming interface and Source equal to the
            source address of the current packet.  If such an entry does not
            exist, immediately proceed to the next step.  Otherwise, compare
            the entry's LastTS and LastPC field values with the Timestamp
            and PacketCounter values, respectively, of the TS/PC TLV of the
            packet.  That is, refuse the packet if at least one of the
            following two conditions is true:

            *  Timestamp is less than LastTS

            *  Timestamp is equal to LastTS and PacketCounter is not greater
               than LastPC

            Note that the current step may involve byte order conversion.

       4.   Derive a sequence of ESAs, using the procedure defined in
            Section 5.2, with the current interface's sequence of CSAs as
            the input sequence of CSAs, current time as CT, and "receiving"
            as the direction.  If the derived sequence is empty, refuse the
            packet.

       5.   Make a temporary copy of the current packet.

       6.   Pad (see Section 2.2) every HMAC TLV present in the temporary
            copy (not the original packet), using the source address of the
            original packet.

    Ovsienko                      Experimental                     [Page 28]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       7.   Iterate over all the HMAC TLVs of the original input packet (not
            the copy), using their order of appearance in the packet.  For
            each HMAC TLV, look up all ESAs in the derived sequence such
            that 2 plus the digest length of HashAlgo of the ESA is equal to
            Length of the TLV and KeyID of the ESA is equal to the value of
            KeyID of the TLV.  Iterate over these ESAs in the relative order
            of their appearance on the full sequence of ESAs.  Note that
            nesting the iterations the opposite way (over ESAs, then over
            HMAC TLVs) would be wrong.

            For each of these ESAs, compute an HMAC result (see
            Section 2.4), using the temporary copy (not the original packet)
            as Text, HashAlgo of the current ESA as H, and AuthKeyOctets of
            the current ESA as K.  If the current HMAC result exactly
            matches the contents of the Digest field of the current HMAC
            TLV, immediately proceed to the next step.  Otherwise, if the
            number of HMAC computations done for the current packet so far
            is equal to MaxDigestsIn, immediately proceed to the next step.
            Otherwise, follow the normal order of iterations.

            Note that the current step may involve byte order conversion.

       8.   Refuse the input packet unless there was a matching HMAC result
            in the previous step.

       9.   Modify the ANM table, using the same index as for the entry
            lookup above, to contain an entry with LastTS set to the value
            of Timestamp and LastPC set to the value of PacketCounter fields
            of the TS/PC TLV of the current packet.  That is, either add a
            new ANM table entry or update the existing one, depending on the
            result of the entry lookup above.  Reset the entry's aging timer
            to the current value of ANM timeout.

            Note that the current step may involve byte order conversion.

       10.  Accept the input packet.

       Before performing the authentication-specific processing above, an
       implementation SHOULD perform those basic procedures of the original
       protocol that don't take any protocol actions on the contents of the
       packet but that will discard the packet if it is not sufficiently
       well formed for further processing.  Although the exact composition
       of such procedures belongs to the scope of the original protocol, it
       seems reasonable to state that a packet SHOULD be discarded early,
       regardless of whether any authentication-specific processing is due,
       unless its source address conforms to Section 3.1 of [BABEL] and is
       not the receiving speaker's own address (see item (e) of Section 8).

    Ovsienko                      Experimental                     [Page 29]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       Note that RxAuthRequired affects only the final action but not the
       defined flow of authentication-specific processing.  The purpose of
       this is to preserve authentication-specific processing feedback (such
       as log messages and event-counter updates), even with RxAuthRequired
       set to FALSE.  This allows an operator to predict the effect of
       changing RxAuthRequired from FALSE to TRUE during a migration
       scenario (Section 7.3) implementation.

    5.5.  Authentication-Specific Statistics Maintenance

       A Babel speaker implementing this mechanism SHOULD maintain a set of
       counters for the following events, per protocol instance and per
       interface:

       a.  Sending an unauthenticated Babel packet through an interface
           having an empty sequence of CSAs (Section 5.3 item 1).

       b.  Sending an unauthenticated Babel packet with a TS/PC TLV but
           without any HMAC TLVs, due to an empty derived sequence of ESAs
           (Section 5.3 item 4).

       c.  Sending an authenticated Babel packet containing both TS/PC and
           HMAC TLVs (Section 5.3 item 9).

       d.  Accepting a Babel packet received through an interface having an
           empty sequence of CSAs (Section 5.4 item 1).

       e.  Refusing a received Babel packet due to an empty derived sequence
           of ESAs (Section 5.4 item 4).

       f.  Refusing a received Babel packet that does not contain exactly
           one TS/PC TLV (Section 5.4 item 2).

       g.  Refusing a received Babel packet due to the TS/PC TLV failing the
           ANM table check (Section 5.4 item 3).  With possible future
           extensions in mind, in implementations of this mechanism, this
           event SHOULD leave out some small amount, per current (Interface,
           Source, LastTS, LastPC) tuple, of the packets refused due to the
           Timestamp value being equal to LastTS and the PacketCounter value
           being equal to LastPC.

       h.  Refusing a received Babel packet missing any HMAC TLVs
           (Section 5.4 item 8).

       i.  Refusing a received Babel packet due to none of the processed
           HMAC TLVs passing the ESA check (Section 5.4 item 8).

    Ovsienko                      Experimental                     [Page 30]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       j.  Accepting a received Babel packet having both TS/PC and HMAC TLVs
           (Section 5.4 item 10).

       k.  Delivery of a refused packet to the instance of the original
           protocol due to the RxAuthRequired parameter being set to FALSE.

       Note that the terms "accepting" and "refusing" are used in the sense
       of the receiving procedure; that is, "accepting" does not mean a
       packet delivered to the instance of the original protocol purely
       because the RxAuthRequired parameter is set to FALSE.  Event-counter
       readings SHOULD be available to the operator at runtime.

    6.  Implementation Notes

    6.1.  Source Address Selection for Sending

       Section 3.1 of [BABEL] allows for the exchange of protocol datagrams,
       using IPv4, IPv6, or both.  The source address of the datagram is a
       unicast (link-local in the case of IPv6) address.  Within an address
       family used by a Babel speaker, there may be more than one address
       eligible for the exchange and assigned to the same network interface.
       The original specification considers this case out of scope and
       leaves it up to the speaker's network stack to select one particular
       address as the datagram source address, but the sending procedure
       requires (Section 5.3 item 5) exact knowledge of the packet source
       address for proper padding of HMAC TLVs.

       As long as a network interface has more than one address eligible for
       the exchange within the same address family, the Babel speaker SHOULD
       internally choose one of those addresses for Babel packet sending
       purposes and then indicate this choice to both the sending procedure
       and the network stack (see Figure 1 in Appendix A).  Wherever this
       requirement cannot be met, this limitation MUST be clearly stated in
       the system documentation to allow an operator to plan network address
       management accordingly.

    6.2.  Output Buffer Management

       An instance of the original protocol will buffer produced TLVs until
       the buffer becomes full or a delay timer has expired.  This is
       performed independently for each Babel interface, with each buffer
       sized according to the interface MTU (see Sections 3.1 and 4 of
       [BABEL]).

    Ovsienko                      Experimental                     [Page 31]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       Since TS/PC TLVs, HMAC TLVs, and any other TLVs -- and most likely
       the TLVs of the original protocol -- share the same packet space (see
       Figure 2 in Appendix A) and, respectively, the same buffer space, a
       particular portion of each interface buffer needs to be reserved for
       one TS/PC TLV and up to MaxDigestsOut HMAC TLVs.  The amount (R) of
       this reserved buffer space is calculated as follows:

                        R = St + MaxDigestsOut * Sh
                        R = 8  + MaxDigestsOut * (4 + Lmax)

       St      The size of a TS/PC TLV.

       Sh      The size of an HMAC TLV.

       Lmax    The maximum possible digest length in octets for a particular
               interface.  It SHOULD be calculated based on the particular
               interface's sequence of CSAs but MAY be taken as the maximum
               digest length supported by a particular implementation.

       An implementation allowing for a per-interface value of MaxDigestsOut
       or Lmax has to account for a different value of R across different
       interfaces, even interfaces having the same MTU.  An implementation
       allowing for a runtime change to the value of R (due to MaxDigestsOut
       or Lmax) has to take care of the TLVs already buffered by the time of
       the change -- specifically, when the value of R increases.

       The maximum safe value of the MaxDigestsOut parameter depends on the
       interface MTU and maximum digest length used.  In general, at least
       200-300 octets of a Babel packet should always be available to data
       other than TS/PC and HMAC TLVs.  An implementation following the
       requirements of Section 4 of [BABEL] would send packets of 512 octets
       or larger.  If, for example, the maximum digest length is 64 octets
       and the MaxDigestsOut value is 4, the value of R would be 280,
       leaving less than half of a 512-octet packet for any other TLVs.  As
       long as the interface MTU is larger or the digest length is smaller,
       higher values of MaxDigestsOut can be used safely.

    6.3.  Optimizations of Deriving Procedure for ESAs

       The following optimizations of the deriving procedure for ESAs can
       reduce the amount of CPU time consumed by authentication-specific
       processing, preserving an implementation's effective behaviour.

       a.  The most straightforward implementation would treat the deriving
           procedure as a per-packet action, but since the procedure is
           deterministic (its output depends on its input only), it is
           possible to significantly reduce the number of times the
           procedure is performed.

    Ovsienko                      Experimental                     [Page 32]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

           The procedure would obviously return the same result for the same
           input arguments (sequence of CSAs, direction, CT) values.
           However, it is possible to predict when the result will remain
           the same, even for a different input.  That is, when the input
           sequence of CSAs and the direction both remain the same but CT
           changes, the result will remain the same as long as CT's order on
           the time axis (relative to all critical points of the sequence of
           CSAs) remains unchanged.  Here, the critical points are
           KeyStartAccept and KeyStopAccept (for the receiving direction),
           and KeyStartGenerate and KeyStopGenerate (for the sending
           direction), of all keys of all CSAs of the input sequence.  In
           other words, in this case the result will remain the same as long
           as (1) none of the active keys expire and (2) none of the
           inactive keys enter into operation.

           An implementation optimized in this way would perform the full
           deriving procedure for a given (interface, direction) pair only
           after an operator's change to the interface's sequence of CSAs or
           after reaching one of the critical points mentioned above.

       b.  Considering that the sending procedure iterates over at most
           MaxDigestsOut elements of the derived sequence of ESAs
           (Section 5.3 item 5), there would be little sense, in the case of
           the sending direction, in returning more than MaxDigestsOut ESAs
           in the derived sequence.  Note that a similar optimization would
           be relatively difficult in the case of the receiving direction,
           since the number of ESAs actually used in examining a particular
           received packet (not to be confused with the number of HMAC
           computations) depends on additional factors besides just
           MaxDigestsIn.

    6.4.  Duplication of Security Associations

       This specification defines three data structures as finite sequences:
       a KeyChain sequence, an interface's sequence of CSAs, and a sequence
       of ESAs.  There are associated semantics to take into account during
       implementation, in that the same element can appear multiple times at
       different positions of the sequence.  In particular, none of the CSA
       structure fields (including HashAlgo, LocalKeyID, and AuthKeyOctets),
       alone or in a combination, have to be unique within a given CSA, or
       within a given sequence of CSAs, or within all sequences of CSAs of a
       Babel speaker.

       In the CSA space defined in this way, for any two authentication
       keys, their one field (in)equality would not imply another field
       (in)equality.  In other words, it is acceptable to have more than one
       authentication key with the same LocalKeyID or the same
       AuthKeyOctets, or both at a time.  It is a conscious design decision

    Ovsienko                      Experimental                     [Page 33]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       that CSA semantics allow for duplication of security associations.
       Consequently, ESA semantics allow for duplication of intermediate
       ESAs in the sequence until the explicit deduplication (Section 5.2
       item 4).

       One of the intentions of this is to define the security association
       management in a way that allows the addressing of some specifics of
       Babel as a mesh routing protocol.  For example, a system operator
       configuring a Babel speaker to participate in more than one
       administrative domain could find each domain using its own
       authentication key (AuthKeyOctets) under the same LocalKeyID value,
       e.g., a "well-known" or "default" value like 0 or 1.  Since
       reconfiguring the domains to use distinct LocalKeyID values isn't
       always feasible, the multi-domain Babel speaker, using several
       distinct authentication keys under the same LocalKeyID, would make a
       valid use case for such duplication.

       Furthermore, if the operator decided in this situation to migrate one
       of the domains to a different LocalKeyID value in a seamless way, the
       respective Babel speakers would use the same authentication key
       (AuthKeyOctets) under two different LocalKeyID values for the time of
       the transition (see also item (f) of Section 8).  This would make a
       similar use case.

       Another intention of this design decision is to decouple security
       association management from authentication key management as much as
       possible, so that the latter, be it manual keying or a key-management
       protocol, could be designed and implemented independently (as the
       respective reasoning made in Section 3.1 of [RIP2-AUTH] still
       applies).  This way, the additional key-management constraints, if
       any, would remain out of the scope of this authentication mechanism.
       A similar thinking justifies the LocalKeyID field having a bit length
       in an ESA structure definition, but not in that of the CSA.

    7.  Network Management Aspects

    7.1.  Backward Compatibility

       Support of this mechanism is optional.  It does not change the
       default behaviour of a Babel speaker and causes no compatibility
       issues with speakers properly implementing the original Babel
       specification.  Given two Babel speakers -- one implementing this
       mechanism and configured for authenticated exchange (A) and another
       not implementing it (B) -- these speakers would not distribute
       routing information unidirectionally, form a routing loop, or
       experience other protocol logic issues specific purely to the use of
       this mechanism.

    Ovsienko                      Experimental                     [Page 34]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       The Babel design requires a bidirectional neighbour reachability
       condition between two given speakers for a successful exchange of
       routing information.  Apparently, neighbour reachability would be
       unidirectional in the case above.  The presence of TS/PC and HMAC
       TLVs in Babel packets sent by A would be transparent to B, but a lack
       of authentication data in Babel packets sent by B would make them
       effectively invisible to the instance of the original protocol of A.
       Unidirectional links are not specific to the use of this mechanism;
       they naturally exist on their own and are properly detected and coped
       with by the original protocol (see Section 3.4.2 of [BABEL]).

    7.2.  Multi-Domain Authentication

       The receiving procedure treats a packet as authentic as soon as one
       of its HMAC TLVs passes the check against the derived sequence of
       ESAs.  This allows for packet exchange authenticated with multiple
       (hash algorithm, authentication key) pairs simultaneously, in
       combinations as arbitrary as permitted by MaxDigestsIn and
       MaxDigestsOut.

       For example, consider three Babel speakers with one interface each,
       configured with the following CSAs:

       o  speaker A: (hash algorithm H1; key SK1), (hash algorithm H1;
          key SK2)

       o  speaker B: (hash algorithm H1; key SK1)

       o  speaker C: (hash algorithm H1; key SK2)

       Packets sent by A would contain two HMAC TLVs each.  Packets sent by
       B and C would contain one HMAC TLV each.  A and B would authenticate
       the exchange between themselves, using H1 and SK1; A and C would use
       H1 and SK2; B and C would discard each other's packets.

       Consider a similar set of speakers configured with different CSAs:

       o  speaker D: (hash algorithm H2; key SK3), (hash algorithm H3;
          key SK4)

       o  speaker E: (hash algorithm H2; key SK3), (hash algorithm H4;
          keys SK5 and SK6)

       o  speaker F: (hash algorithm H3; keys SK4 and SK7), (hash
          algorithm H5; key SK8)

    Ovsienko                      Experimental                     [Page 35]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       Packets sent by D would contain two HMAC TLVs each.  Packets sent by
       E and F would contain three HMAC TLVs each.  D and E would
       authenticate the exchange between themselves, using H2 and SK3; D and
       F would use H3 and SK4; E and F would discard each other's packets.
       The simultaneous use of H4, SK5, and SK6 by E, as well as the use of
       SK7, H5, and SK8 by F (for their own purposes), would remain
       insignificant to D.

       An operator implementing multi-domain authentication should keep in
       mind that values of MaxDigestsIn and MaxDigestsOut may be different
       both within the same Babel speaker and across different speakers.
       Since the minimum value of both parameters is 2 (see Sections 3.4 and
       3.5), when more than two authentication domains are configured
       simultaneously it is advisable to confirm that every involved speaker
       can handle a sufficient number of HMAC results for both sending and
       receiving.

       The recommended method of Babel speaker configuration for
       multi-domain authentication is to not only use a different
       authentication key for each domain but also a separate CSA for each
       domain, even when hash algorithms are the same.  This allows for fair
       competition between CSAs and sometimes limits the consequences of a
       possible misconfiguration to the scope of one CSA.  See also item (f)
       of Section 8.

    7.3.  Migration to and from Authenticated Exchange

       It is common in practice to consider a migration to the authenticated
       exchange of routing information only after the network has already
       been deployed and put into active use.  Performing the migration in a
       way without regular traffic interruption is typically demanded, and
       this specification allows a smooth migration using the RxAuthRequired
       interface parameter defined in Section 3.1.  This measure is similar
       to the "transition mode" suggested in Section 5 of [OSPF3-AUTH-BIS].

       An operator performing the migration needs to arrange configuration
       changes as follows:

       1.  Decide on particular hash algorithm(s) and key(s) to be used.

       2.  Identify all speakers and their involved interfaces that need to
           be migrated to authenticated exchange.

       3.  For each of the speakers and the interfaces to be reconfigured,
           first set the RxAuthRequired parameter to FALSE, then configure
           necessary CSA(s).

    Ovsienko                      Experimental                     [Page 36]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       4.  Examine the speakers to confirm that Babel packets are
           successfully authenticated according to the configuration (for
           instance, by examining ANM table entries and authentication-
           specific statistics; see Figure 1 in Appendix A), and address any
           discrepancies before proceeding further.

       5.  For each of the speakers and the reconfigured interfaces, set the
           RxAuthRequired parameter to TRUE.

       Likewise, temporarily setting RxAuthRequired to FALSE can be used to
       migrate smoothly from an authenticated packet exchange back to an
       unauthenticated one.

    7.4.  Handling of Authentication Key Exhaustion

       This specification employs a common concept of multiple
       authentication keys coexisting for a given interface, with two
       independent lifetime ranges associated with each key (one for sending
       and another for receiving).  It is typically recommended that the
       keys be configured using finite lifetimes, adding new keys before the
       old keys expire.  However, it is obviously possible for all keys to
       expire for a given interface (for sending, receiving, or both).
       Possible ways of addressing this situation raise their own concerns:

       o  Automatic switching to unauthenticated protocol exchange.  This
          behaviour invalidates the initial purposes of authentication and
          is commonly viewed as unacceptable ([RIP2-AUTH] Section 5.1,
          [OSPF2-AUTH] Section 3.2, and [OSPF3-AUTH-BIS] Section 3).

       o  Stopping routing information exchange over the interface.  This
          behaviour is likely to impact regular traffic routing and is
          commonly viewed as "not advisable" ([RIP2-AUTH], [OSPF2-AUTH], and
          [OSPF3-AUTH]), although [OSPF3-AUTH-BIS] is different in this
          regard.

       o  The use of the "most recently expired" key over its intended
          lifetime range.  This behaviour is recommended for implementation
          in [RIP2-AUTH], [OSPF2-AUTH], and [OSPF3-AUTH] but not in
          [OSPF3-AUTH-BIS].  Such use of this key may become a problem, due
          to an offline cryptographic attack (see item (f) of Section 8) or
          a compromise of the key.  In addition, distinguishing a recently
          expired key from a key that has never been used may be impossible
          after a router restart.

       The design of this mechanism prevents automatic switching to
       unauthenticated exchange and is consistent with similar
       authentication mechanisms in this regard, but since the best choice
       between two other options depends on local site policy, this decision

    Ovsienko                      Experimental                     [Page 37]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       is left up to the operator rather than the implementor (in a way
       resembling the "fail secure" configuration knob described in
       Section 5.1 of [RIP2-AUTH]).

       Although the deriving procedure does not allow for any exceptions in
       the filtering of expired keys (Section 5.2 item 2), the operator can
       trivially enforce one of the two remaining behaviour options through
       local key-management procedures.  In particular, when using the key
       over its intended lifetime is preferable to regular traffic
       disruption, the operator would explicitly leave the old key expiry
       time open until the new key is added to the router configuration.  In
       the opposite case, the operator would always configure the old key
       with a finite lifetime and bear associated risks.

    8.  Security Considerations

       The use of this mechanism implies requirements common to the use of
       shared authentication keys, including, but not limited to:

       o  holding the keys secret,

       o  including sufficient amounts of random bits into each key,

       o  rekeying on a regular basis, and

       o  never reusing a used key for a different purpose.

       That said, proper design and implementation of a key-management
       policy are out of the scope of this work.  Many publications on this
       subject exist and should be used for this purpose (BCP 107 [RFC4107],
       BCP 132 [RFC4962], and [RFC6039] are suggested as starting points).

       It is possible for a network that exercises rollover of
       authentication keys to experience accidental expiration of all the
       keys for a network interface, as discussed at greater length in
       Section 7.4.  With that and the guidance of Section 5.1 of
       [RIP2-AUTH] in mind, in such an event the Babel speaker MUST send a
       "last key expired" notification to the operator (e.g., via syslog,
       SNMP, and/or other implementation-specific means), most likely in
       relation to item (b) of Section 5.5.  Also, any actual occurrence of
       an authentication key expiration MUST cause a security event to be
       logged by the implementation.  The log item MUST include at least a
       note that the authentication key has expired, the Babel routing
       protocol instance(s) affected, the network interface(s) affected, the
       LocalKeyID that is affected, and the current date/time.  Operators
       are encouraged to check such logs as an operational security
       practice.

    Ovsienko                      Experimental                     [Page 38]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       Considering particular attacks being in scope or out of scope on one
       hand and measures taken to protect against particular in-scope
       attacks on the other, the original Babel protocol and this
       authentication mechanism are in line with similar datagram-based
       routing protocols and their respective mechanisms.  In particular,
       the primary concerns addressed are:

       a.  Peer Entity Authentication

           The Babel speaker authentication mechanism defined herein is
           believed to be as strong as the class itself to which it belongs.
           This specification is built on fundamental concepts implemented
           for authentication of similar routing protocols: per-packet
           authentication, the use of the HMAC construction, and the use of
           shared keys.  Although this design approach does not address all
           possible concerns, it is so far known to be sufficient for most
           practical cases.

       b.  Data Integrity

           Meaningful parts of a Babel datagram are the contents of the
           Babel packet (in the definition of Section 4.2 of [BABEL]) and
           the source address of the datagram (Section 3.5.3 of [BABEL]).
           This mechanism authenticates both parts, using the HMAC
           construction, so that making any meaningful change to an
           authenticated packet after it has been emitted by the sender
           should be as hard as attacking the HMAC construction itself or
           successfully recovering the authentication key.

           Note well that any trailing data of the Babel datagram is not
           meaningful in the scope of the original specification and does
           not belong to the Babel packet.  Integrity of the trailing data
           is thus not protected by this mechanism.  At the same time,
           although any TLV extra data is also not meaningful in the same
           scope, its integrity is protected, since this extra data is a
           part of the Babel packet (see Figure 2 in Appendix A).

       c.  Denial of Service

           Proper deployment of this mechanism in a Babel network
           significantly increases the efforts required for an attacker to
           feed arbitrary Babel packets into a protocol exchange (with the
           intent of attacking a particular Babel speaker or disrupting the
           exchange of regular traffic in a routing domain).  It also
           protects the neighbour table from being flooded with forged
           speaker entries.

    Ovsienko                      Experimental                     [Page 39]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

           At the same time, this protection comes with a price of CPU time
           being spent on HMAC computations.  This may be a concern for
           low-performance CPUs combined with high-speed interfaces, as
           sometimes seen in embedded systems and hardware routers.  The
           MaxDigestsIn parameter, which is used to limit the maximum amount
           of CPU time spent on a single received Babel packet, addresses
           this concern to some extent.

       d.  Reflection Attacks

           Given the approach discussed in item (b), the only potential
           reflection attack on this mechanism could be replaying exact
           copies of Babel packets back to the sender from the same source
           address.  The mitigation in this case is straightforward and is
           discussed in Section 5.4.

       The following in-scope concern is only partially addressed:

       e.  Replay Attacks

           This specification establishes a basic replay protection measure
           (see Section 3.6), defines a timeout parameter affecting its
           strength (see Section 3.7), and outlines implementation methods
           also affecting protection strength in several ways (see
           Section 5.1).  The implementor's choice of the timeout value and
           particular implementation methods may be suboptimal due to, for
           example, insufficient hardware resources of the Babel speaker.

           Furthermore, it may be possible that an operator configures the
           timeout and the methods to address particular local specifics,
           and this further weakens the protection.  An operator concerned
           about replay attack protection strength should understand these
           factors and their meaning in a given network segment.

           That said, a particular form of replay attack on this mechanism
           remains possible anyway.  Whether there are two or more network
           segments using the same CSA and there is an adversary that
           captures Babel packets on one segment and replays on another (and
           vice versa, due to the bidirectional reachability requirement for
           neighbourship), some of the speakers on one such segment will
           detect the "virtual" neighbours from another and may prefer them
           for some destinations.  This applies even more so as Babel
           doesn't require a common pre-configured network prefix between
           neighbours.

    Ovsienko                      Experimental                     [Page 40]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

           A reliable solution to this particular problem, which Section 4.5
           of [RFC7186] discusses as well, is not currently known.  It is
           recommended that the operators use distinct CSAs for distinct
           network segments.

       The following in-scope concerns are not addressed:

       f.  Offline Cryptographic Attacks

           This mechanism is obviously subject to offline cryptographic
           attacks.  As soon as an attacker has obtained a copy of an
           authenticated Babel packet of interest (which gets easier to do
           in wireless networks), he has all of the parameters of the
           authentication-specific processing performed by the sender,
           except for authentication key(s) and the choice of particular
           hash algorithm(s).  Since digest lengths of common hash
           algorithms are well known and can be matched with those seen in
           the packet, the complexity of this attack is essentially that of
           the authentication key attack.

           Viewing the cryptographic strength of particular hash algorithms
           as a concern of its own, the main practical means of resisting
           offline cryptographic attacks on this mechanism are periodic
           rekeying and the use of strong keys with a sufficient number of
           random bits.

           It is important to understand that in the case of multiple keys
           being used within a single interface (for multi-domain
           authentication or during a key rollover) the strength of the
           combined configuration would be that of the weakest key, since
           only one successful HMAC test is required for an authentic
           packet.  Operators concerned about offline cryptographic attacks
           should enforce the same strength policy for all keys used for a
           given interface.

           Note that a special pathological case is possible with this
           mechanism.  Whenever two or more authentication keys are
           configured for a given interface such that all keys share the
           same AuthKeyOctets and the same HashAlgo, but LocalKeyID modulo
           2^16 is different for each key, these keys will not be treated as
           duplicate (Section 5.2 item 4), but an HMAC result computed for a
           given packet will be the same for each of these keys.  In the
           case of the sending procedure, this can produce multiple HMAC
           TLVs with exactly the same value of the Digest field but
           different values of the KeyID field.  In this case, the attacker
           will see that the keys are the same, even without knowledge of

    Ovsienko                      Experimental                     [Page 41]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

           the key itself.  The reuse of authentication keys is not the
           intended use case of this mechanism and should be strongly
           avoided.

       g.  Non-repudiation

           This specification relies on the use of shared keys.  There is no
           timestamp infrastructure and no key-revocation mechanism defined
           to address the compromise of a shared key.  Establishing the time
           that a particular authentic Babel packet was generated is thus
           not possible.  Proving that a particular Babel speaker had
           actually sent a given authentic packet is also impossible as soon
           as the shared key is claimed compromised.  Even if the shared key
           is not compromised, reliably identifying the speaker that had
           actually sent a given authentic Babel packet is not possible.
           Since any of the speakers sharing a key can impersonate any other
           speaker sharing the same key, it is only possible to prove that
           the speaker belongs to the group sharing the key.

       h.  Confidentiality Violations

           The original Babel protocol does not encrypt any of the
           information contained in its packets.  The contents of a Babel
           packet are trivial to decode and thus can reveal network topology
           details.  This mechanism does not improve this situation in any
           way.  Since routing protocol messages are not the only kind of
           information subject to confidentiality concerns, a complete
           solution to this problem is likely to include measures based on
           the channel security model, such as IPsec and Wi-Fi Protected
           Access 2 (WPA2) at the time of this writing.

       i.  Key Management

           Any authentication key exchange/distribution concerns are out of
           scope.  However, the internal representation of authentication
           keys (see Section 3.8) allows implementations to use such diverse
           key-management techniques as manual configuration, a provisioning
           system, a key-management protocol, or any other means that comply
           with this specification.

       j.  Message Deletion

           Any message deletion attacks are out of scope.  Since a datagram
           deleted by an attacker cannot be distinguished from a datagram
           naturally lost in transmission, and since datagram-based routing
           protocols are designed to withstand a certain loss of packets,

    Ovsienko                      Experimental                     [Page 42]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

           the currently established practice is treating authentication
           purely as a per-packet function, without any added detection of
           lost packets.

    9.  IANA Considerations

       At the time of publication of this document, the Babel TLV Types
       namespace did not have an IANA registry.  TLV types 11 and 12 were
       assigned (see Table 1 in Appendix A) to the TS/PC and HMAC TLV types
       by Juliusz Chroboczek, designer of the original Babel protocol.
       Therefore, this document has no IANA actions.

    10.  Acknowledgements

       Thanks to Randall Atkinson and Matthew Fanto for their comprehensive
       work on [RIP2-AUTH] that initiated a series of publications on
       routing protocol authentication, including this one.  This
       specification adopts many concepts belonging to the whole series.

       Thanks to Juliusz Chroboczek, Gabriel Kerneis, and Matthieu Boutier.
       This document incorporates many technical and editorial corrections
       based on their feedback.  Thanks to all contributors to Babel,
       because this work would not be possible without the prior works.
       Thanks to Dominic Mulligan for editorial proofreading of this
       document.  Thanks to Riku Hietamaki for suggesting the test vectors
       section.

       Thanks to Joel Halpern, Jim Schaad, Randall Atkinson, and Stephen
       Farrell for providing (in chronological order) valuable feedback on
       earlier versions of this document.

       Thanks to Jim Gettys and Dave Taht for developing the CeroWrt
       wireless router project and collaborating on many integration issues.
       A practical need for Babel authentication emerged during research
       based on CeroWrt that eventually became the very first use case of
       this mechanism.

       Thanks to Kunihiro Ishiguro and Paul Jakma for establishing the GNU
       Zebra and Quagga routing software projects, respectively.  Thanks to
       Werner Koch, the author of Libgcrypt.  The very first implementation
       of this mechanism was made on a base of Quagga and Libgcrypt.

    Ovsienko                      Experimental                     [Page 43]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

    11.  References

    11.1.  Normative References

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

       [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

       [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
                  Architecture", RFC 4291, February 2006.

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

       [BABEL]    Chroboczek, J., "The Babel Routing Protocol", RFC 6126,
                  April 2011.

    11.2.  Informative References

       [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
                  and M. Carney, "Dynamic Host Configuration Protocol for
                  IPv6 (DHCPv6)", RFC 3315, July 2003.

       [RFC3931]  Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
                  Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.

       [RFC4030]  Stapp, M. and T. Lemon, "The Authentication Suboption for
                  the Dynamic Host Configuration Protocol (DHCP) Relay Agent
                  Option", RFC 4030, March 2005.

       [RFC4107]  Bellovin, S. and R. Housley, "Guidelines for Cryptographic
                  Key Management", BCP 107, RFC 4107, June 2005.

       [RFC4270]  Hoffman, P. and B. Schneier, "Attacks on Cryptographic
                  Hashes in Internet Protocols", RFC 4270, November 2005.

       [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
                  December 2005.

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

    Ovsienko                      Experimental                     [Page 44]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       [RFC4962]  Housley, R. and B. Aboba, "Guidance for Authentication,
                  Authorization, and Accounting (AAA) Key Management",
                  BCP 132, RFC 4962, July 2007.

       [RFC5176]  Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
                  Aboba, "Dynamic Authorization Extensions to Remote
                  Authentication Dial In User Service (RADIUS)", RFC 5176,
                  January 2008.

       [ISIS-AUTH-A]
                  Li, T. and R. Atkinson, "IS-IS Cryptographic
                  Authentication", RFC 5304, October 2008.

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

       [OSPF2-AUTH]
                  Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
                  Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
                  Authentication", RFC 5709, October 2009.

       [RFC6039]  Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues
                  with Existing Cryptographic Protection Methods for Routing
                  Protocols", RFC 6039, October 2010.

       [RFC6151]  Turner, S. and L. Chen, "Updated Security Considerations
                  for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
                  RFC 6151, March 2011.

       [RFC6194]  Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
                  Considerations for the SHA-0 and SHA-1 Message-Digest
                  Algorithms", RFC 6194, March 2011.

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

       [RFC6709]  Carpenter, B., Aboba, B., and S. Cheshire, "Design
                  Considerations for Protocol Extensions", RFC 6709,
                  September 2012.

       [BABEL-EXTENSION]
                  Chroboczek, J., "Extension Mechanism for the Babel Routing
                  Protocol", Work in Progress, June 2014.

    Ovsienko                      Experimental                     [Page 45]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       [OSPF3-AUTH-BIS]
                  Bhatia, M., Manral, V., and A. Lindem, "Supporting
                  Authentication Trailer for OSPFv3", RFC 7166, March 2014.

       [RFC7183]  Herberg, U., Dearlove, C., and T. Clausen, "Integrity
                  Protection for the Neighborhood Discovery Protocol (NHDP)
                  and Optimized Link State Routing Protocol Version 2
                  (OLSRv2)", RFC 7183, April 2014.

       [RFC7186]  Yi, J., Herberg, U., and T. Clausen, "Security Threats for
                  the Neighborhood Discovery Protocol (NHDP)", RFC 7186,
                  April 2014.

    Ovsienko                      Experimental                     [Page 46]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

    Appendix A.  Figures and Tables

          +-------------------------------------------------------------+
          |              authentication-specific statistics             |
          +-------------------------------------------------------------+
            ^                            |                            ^
            |                            v                            |
            |    +-----------------------------------------------+    |
            |    |                system operator                |    |
            |    +-----------------------------------------------+    |
            |        ^ |      ^ |       ^ |       ^ |      ^ |        |
            |        | v      | |       | |       | |      | v        |
          +---+  +---------+  | |       | |       | |  +---------+  +---+
          |   |->|   ANM   |  | |       | |       | |  | LocalTS |->|   |
          | R |<-|  table  |  | |       | |       | |  | LocalPC |<-| T |
          | x |  +---------+  | v       | v       | v  +---------+  | x |
          |   |  +----------------+ +---------+ +----------------+  |   |
          | p |  | MaxDigestsIn   | |         | | MaxDigestsOut  |  | p |
          | r |<-| ANM timeout    | |  CSAs   | |                |->| r |
          | o |  | RxAuthRequired | |         | |                |  | o |
          | c |  +----------------+ +---------+ +----------------+  | c |
          | e |  +-------------+     |       |     +-------------+  | e |
          | s |  |   Rx ESAs   |     |       |     |   Tx ESAs   |  | s |
          | s |<-| (temporary) |<----+       +---->| (temporary) |->| s |
          | i |  +-------------+                   +-------------+  | i |
          | n |  +------------------------------+----------------+  | n |
          | g |  |     instance of              | output buffers |=>| g |
          |   |=>|     the original             +----------------+  |   |
          |   |  |     protocol                 | source address |->|   |
          +---+  +------------------------------+----------------+  +---+
           /\                                            |            ||
           ||                                            v            \/
          +-------------------------------------------------------------+
          |                        network stack                        |
          +-------------------------------------------------------------+
             /\ ||       /\ ||                       /\ ||       /\ ||
             || \/       || \/                       || \/       || \/
          +---------+ +---------+                 +---------+ +---------+
          | speaker | | speaker |       ...       | speaker | | speaker |
          +---------+ +---------+                 +---------+ +---------+

          Flow of control data           : --->
          Flow of Babel datagrams/packets: ===>

                           Figure 1: Interaction Diagram

    Ovsienko                      Experimental                     [Page 47]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

                      P
       |<---------------------------->|                                 (D1)
       |                B             |
       |  |<------------------------->|
       |  |                           |
       +--+-----+-----+...+-----+-----+--+   P: Babel packet
       |H |some |some |   |some |some |T |   H: Babel packet header
       |  |TLV  |TLV  |   |TLV  |TLV  |  |   B: Babel packet body
       |  |     |     |   |     |     |  |   T: optional trailing data block
       +--+-----+-----+...+-----+-----+--+

                                   P
       |<----------------------------------------------------->|        (D2)
       |                             B                         |
       |  |<-------------------------------------------------->|
       |  |                                                    |
       +--+-----+-----+...+-----+-----+------+------+...+------+--+
       |H |some |some |   |some |some |TS/PC |HMAC  |   |HMAC  |T |
       |  |TLV  |TLV  |   |TLV  |TLV  |TLV   |TLV 1 |   |TLV n |  |
       |  |     |     |   |     |     |      |      |   |      |  |
       +--+-----+-----+...+-----+-----+------+------+...+------+--+

                                   P
       |<----------------------------------------------------->|        (D3)
       |                             B                         |
       |  |<-------------------------------------------------->|
       |  |                                                    |
       +--+------+------+...+------+-----+-----+...+-----+-----+--+
       |H |TS/PC |HMAC  |   |HMAC  |some |some |   |some |some |T |
       |  |TLV   |TLV 1 |   |TLV n |TLV  |TLV  |   |TLV  |TLV  |  |
       |  |      |      |   |      |     |     |   |     |     |  |
       +--+------+------+...+------+-----+-----+...+-----+-----+--+

                                      P
       |<------------------------------------------------------------>| (D4)
       |                                B                             |
       |  |<--------------------------------------------------------->|
       |  |                                                           |
       +--+-----+------+-----+------+...+-----+------+...+------+-----+--+
       |H |some |HMAC  |some |HMAC  |   |some |HMAC  |   |TS/PC |some |T |
       |  |TLV  |TLV 1 |TLV  |TLV 2 |   |TLV  |TLV n |   |TLV   |TLV  |  |
       |  |     |      |     |      |   |     |      |   |      |     |  |
       +--+-----+------+-----+------+...+-----+------+...+------+-----+--+

                        Figure 2: Babel Datagram Structure

    Ovsienko                      Experimental                     [Page 48]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

                +-------+-------------------------+---------------+
                | Value | Name                    | Reference     |
                +-------+-------------------------+---------------+
                |     0 | Pad1                    | [BABEL]       |
                |     1 | PadN                    | [BABEL]       |
                |     2 | Acknowledgement Request | [BABEL]       |
                |     3 | Acknowledgement         | [BABEL]       |
                |     4 | Hello                   | [BABEL]       |
                |     5 | IHU                     | [BABEL]       |
                |     6 | Router-Id               | [BABEL]       |
                |     7 | Next Hop                | [BABEL]       |
                |     8 | Update                  | [BABEL]       |
                |     9 | Route Request           | [BABEL]       |
                |    10 | Seqno Request           | [BABEL]       |
                |    11 | TS/PC                   | this document |
                |    12 | HMAC                    | this document |
                +-------+-------------------------+---------------+

                       Table 1: Babel TLV Types 0 through 12

        +--------------+-----------------------------+-------------------+
        | Packet field | Packet octets (hexadecimal) | Meaning (decimal) |
        +--------------+-----------------------------+-------------------+
        | Magic        | 2a                          | 42                |
        | Version      | 02                          | version 2         |
        | Body length  | 00:14                       | 20 octets         |
        | [TLV] Type   | 04                          | 4 (Hello)         |
        | [TLV] Length | 06                          | 6 octets          |
        | Reserved     | 00:00                       | no meaning        |
        | Seqno        | 09:25                       | 2341              |
        | Interval     | 01:90                       | 400 (4.00 s)      |
        | [TLV] Type   | 08                          | 8 (Update)        |
        | [TLV] Length | 0a                          | 10 octets         |
        | AE           | 00                          | 0 (wildcard)      |
        | Flags        | 40                          | default router-id |
        | Plen         | 00                          | 0 bits            |
        | Omitted      | 00                          | 0 bits            |
        | Interval     | ff:ff                       | infinity          |
        | Seqno        | 68:21                       | 26657             |
        | Metric       | ff:ff                       | infinity          |
        +--------------+-----------------------------+-------------------+

                Table 2: A Babel Packet without Authentication TLVs

    Ovsienko                      Experimental                     [Page 49]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       +---------------+-------------------------------+-------------------+
       | Packet field  | Packet octets (hexadecimal)   | Meaning (decimal) |
       +---------------+-------------------------------+-------------------+
       | Magic         | 2a                            | 42                |
       | Version       | 02                            | version 2         |
       | Body length   | 00:4c                         | 76 octets         |
       | [TLV] Type    | 04                            | 4 (Hello)         |
       | [TLV] Length  | 06                            | 6 octets          |
       | Reserved      | 00:00                         | no meaning        |
       | Seqno         | 09:25                         | 2341              |
       | Interval      | 01:90                         | 400 (4.00 s)      |
       | [TLV] Type    | 08                            | 8 (Update)        |
       | [TLV] Length  | 0a                            | 10 octets         |
       | AE            | 00                            | 0 (wildcard)      |
       | Flags         | 40                            | default router-id |
       | Plen          | 00                            | 0 bits            |
       | Omitted       | 00                            | 0 bits            |
       | Interval      | ff:ff                         | infinity          |
       | Seqno         | 68:21                         | 26657             |
       | Metric        | ff:ff                         | infinity          |
       | [TLV] Type    | 0b                            | 11 (TS/PC)        |
       | [TLV] Length  | 06                            | 6 octets          |
       | PacketCounter | 00:01                         | 1                 |
       | Timestamp     | 52:1d:7e:8b                   | 1377664651        |
       | [TLV] Type    | 0c                            | 12 (HMAC)         |
       | [TLV] Length  | 16                            | 22 octets         |
       | KeyID         | 00:c8                         | 200               |
       | Digest        | fe:80:00:00:00:00:00:00:0a:11 | padding           |
       |               | 96:ff:fe:1c:10:c8:00:00:00:00 |                   |
       | [TLV] Type    | 0c                            | 12 (HMAC)         |
       | [TLV] Length  | 16                            | 22 octets         |
       | KeyID         | 00:64                         | 100               |
       | Digest        | fe:80:00:00:00:00:00:00:0a:11 | padding           |
       |               | 96:ff:fe:1c:10:c8:00:00:00:00 |                   |
       +---------------+-------------------------------+-------------------+

       Table 3: A Babel Packet with Each HMAC TLV Padded Using IPv6 Address
                             fe80::0a11:96ff:fe1c:10c8

    Ovsienko                      Experimental                     [Page 50]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       +---------------+-------------------------------+-------------------+
       | Packet field  | Packet octets (hexadecimal)   | Meaning (decimal) |
       +---------------+-------------------------------+-------------------+
       | Magic         | 2a                            | 42                |
       | Version       | 02                            | version 2         |
       | Body length   | 00:4c                         | 76 octets         |
       | [TLV] Type    | 04                            | 4 (Hello)         |
       | [TLV] Length  | 06                            | 6 octets          |
       | Reserved      | 00:00                         | no meaning        |
       | Seqno         | 09:25                         | 2341              |
       | Interval      | 01:90                         | 400 (4.00 s)      |
       | [TLV] Type    | 08                            | 8 (Update)        |
       | [TLV] Length  | 0a                            | 10 octets         |
       | AE            | 00                            | 0 (wildcard)      |
       | Flags         | 40                            | default router-id |
       | Plen          | 00                            | 0 bits            |
       | Omitted       | 00                            | 0 bits            |
       | Interval      | ff:ff                         | infinity          |
       | Seqno         | 68:21                         | 26657             |
       | Metric        | ff:ff                         | infinity          |
       | [TLV] Type    | 0b                            | 11 (TS/PC)        |
       | [TLV] Length  | 06                            | 6 octets          |
       | PacketCounter | 00:01                         | 1                 |
       | Timestamp     | 52:1d:7e:8b                   | 1377664651        |
       | [TLV] Type    | 0c                            | 12 (HMAC)         |
       | [TLV] Length  | 16                            | 22 octets         |
       | KeyID         | 00:c8                         | 200               |
       | Digest        | c6:f1:06:13:30:3c:fa:f3:eb:5d | HMAC result       |
       |               | 60:3a:ed:fd:06:55:83:f7:ee:79 |                   |
       | [TLV] Type    | 0c                            | 12 (HMAC)         |
       | [TLV] Length  | 16                            | 22 octets         |
       | KeyID         | 00:64                         | 100               |
       | Digest        | df:32:16:5e:d8:63:16:e5:a6:4d | HMAC result       |
       |               | c7:73:e0:b5:22:82:ce:fe:e2:3c |                   |
       +---------------+-------------------------------+-------------------+

       Table 4: A Babel Packet with Each HMAC TLV Containing an HMAC Result

    Ovsienko                      Experimental                     [Page 51]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

    Appendix B.  Test Vectors

       The test vectors below may be used to verify the correctness of some
       procedures performed by an implementation of this mechanism, namely:

       o  appending TS/PC and HMAC TLVs to the Babel packet body,

       o  padding the HMAC TLV(s),

       o  computation of the HMAC result(s), and

       o  placement of the result(s) in the TLV(s).

       This verification isn't exhaustive.  There are other important
       implementation aspects that would require testing methods of
       their own.

       The test vectors were produced as follows.

       1.  A Babel speaker with a network interface with IPv6 link-local
           address fe80::0a11:96ff:fe1c:10c8 was configured to use two CSAs
           for the interface:

           *  CSA1={HashAlgo=RIPEMD-160, KeyChain={{LocalKeyID=200,
              AuthKeyOctets=Key26}}}

           *  CSA2={HashAlgo=SHA-1, KeyChain={{LocalKeyId=100,
              AuthKeyOctets=Key70}}}

           The authentication keys above are:

           *  Key26 in ASCII:

              ABCDEFGHIJKLMNOPQRSTUVWXYZ

           *  Key26 in hexadecimal:

              41:42:43:44:45:46:47:48:49:4a:4b:4c:4d:4e:4f:50
              51:52:53:54:55:56:57:58:59:5a

           *  Key70 in ASCII:

      This=key=is=exactly=70=octets=long.=ABCDEFGHIJKLMNOPQRSTUVWXYZ01234567

    Ovsienko                      Experimental                     [Page 52]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

           *  Key70 in hexadecimal:

              54:68:69:73:3d:6b:65:79:3d:69:73:3d:65:78:61:63
              74:6c:79:3d:37:30:3d:6f:63:74:65:74:73:3d:6c:6f
              6e:67:2e:3d:41:42:43:44:45:46:47:48:49:4a:4b:4c
              4d:4e:4f:50:51:52:53:54:55:56:57:58:59:5a:30:31
              32:33:34:35:36:37

           The length of each key was picked to relate (using the terms
           listed in Section 2.4) to the properties of its respective hash
           algorithm as follows:

           *  the digest length (L) of both RIPEMD-160 and SHA-1 is 20
              octets,

           *  the internal block size (B) of both RIPEMD-160 and SHA-1 is 64
              octets,

           *  the length of Key26 (26) is greater than L but less than B,
              and

           *  the length of Key70 (70) is greater than B (and thus greater
              than L).

           KeyStartAccept, KeyStopAccept, KeyStartGenerate, and
           KeyStopGenerate were set to make both authentication keys valid.

       2.  The instance of the original protocol of the speaker produced a
           Babel packet (PktO) to be sent from the interface.  Table 2
           provides a decoding of PktO, the contents of which are below:

           2a:02:00:14:04:06:00:00:09:25:01:90:08:0a:00:40
           00:00:ff:ff:68:21:ff:ff

       3.  The authentication mechanism appended one TS/PC TLV and two HMAC
           TLVs to the packet body, updated the "Body length" packet header
           field, and padded the Digest field of the HMAC TLVs, using the
           link-local IPv6 address of the interface and the necessary amount
           of zeroes.  Table 3 provides a decoding of the resulting
           temporary packet (PktT), the contents of which are below:

           2a:02:00:4c:04:06:00:00:09:25:01:90:08:0a:00:40
           00:00:ff:ff:68:21:ff:ff:0b:06:00:01:52:1d:7e:8b
           0c:16:00:c8:fe:80:00:00:00:00:00:00:0a:11:96:ff
           fe:1c:10:c8:00:00:00:00:0c:16:00:64:fe:80:00:00
           00:00:00:00:0a:11:96:ff:fe:1c:10:c8:00:00:00:00

    Ovsienko                      Experimental                     [Page 53]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

       4.  The authentication mechanism produced two HMAC results,
           performing the computations as follows:

           *  For H=RIPEMD-160, K=Key26, and Text=PktT, the HMAC result is:

              c6:f1:06:13:30:3c:fa:f3:eb:5d:60:3a:ed:fd:06:55
              83:f7:ee:79

           *  For H=SHA-1, K=Key70, and Text=PktT, the HMAC result is:

              df:32:16:5e:d8:63:16:e5:a6:4d:c7:73:e0:b5:22:82
              ce:fe:e2:3c

       5.  The authentication mechanism placed each HMAC result into its
           respective HMAC TLV, producing the final authenticated Babel
           packet (PktA), which was eventually sent from the interface.

           Table 4 provides a decoding of PktA, the contents of which are
           below:

           2a:02:00:4c:04:06:00:00:09:25:01:90:08:0a:00:40
           00:00:ff:ff:68:21:ff:ff:0b:06:00:01:52:1d:7e:8b
           0c:16:00:c8:c6:f1:06:13:30:3c:fa:f3:eb:5d:60:3a
           ed:fd:06:55:83:f7:ee:79:0c:16:00:64:df:32:16:5e
           d8:63:16:e5:a6:4d:c7:73:e0:b5:22:82:ce:fe:e2:3c

       Interpretation of this process is to be done differently for the
       sending and receiving directions (see Figure 1).

       For the sending direction, given a Babel speaker configured using the
       IPv6 address and the sequence of CSAs as described above, the
       implementation SHOULD (see notes in Section 5.3) produce exactly the
       temporary packet PktT if the original protocol instance produces
       exactly the packet PktO to be sent from the interface.  If the
       temporary packet exactly matches PktT, the HMAC results computed
       afterwards MUST exactly match the respective results above, and the
       final authenticated packet MUST exactly match PktA above.

       For the receiving direction, given a Babel speaker configured using
       the sequence of CSAs as described above (but a different IPv6
       address), the implementation MUST (assuming that the TS/PC check
       didn't fail) produce exactly the temporary packet PktT above if its
       network stack receives through the interface exactly the packet PktA
       above from the source IPv6 address above.  The first HMAC result
       computed afterwards MUST match the first result above.  The receiving
       procedure doesn't compute the second HMAC result in this case, but if
       the implementor decides to compute it anyway for verification
       purposes, it MUST exactly match the second result above.

    Ovsienko                      Experimental                     [Page 54]

    RFC 7298         Babel HMAC Cryptographic Authentication       July 2014

    Author's Address

       Denis Ovsienko
       Yandex
       16, Leo Tolstoy St.
       Moscow  119021
       Russia

       EMail: infrastation@yandex.ru

    Ovsienko                      Experimental                     [Page 55]