Independent Submission D. Ovsienko
Request for Comments: 7298 Yandex
Updates: 6126 July 2014
Babel Hashed Message Authentication Code (HMAC)
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
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
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.
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
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
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
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.
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
An implementation of this mechanism MUST include support for two hash
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
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
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
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
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
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
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
* the given source address, if it is an IPv6 address, or
* the IPv4-mapped IPv6 address (per Section 126.96.36.199 of
[RFC4291]) holding the given source address, if it is an IPv4
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).
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.
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
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
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.
A First-Hash, also known as the inner hash, is computed
First-Hash = H(Ko XOR Ipad || Text)
A Second-Hash, also known as the outer hash, is computed
Second-Hash = H(Ko XOR Opad || First-Hash)
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).