One document matched: draft-ovsienko-babel-hmac-authentication-09.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="2"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="exp" updates="6126" docName="draft-ovsienko-babel-hmac-authentication-09" ipr="trust200902">
<front>
<title>Babel HMAC Cryptographic Authentication</title>
<author fullname="Denis Ovsienko" initials="D." surname="Ovsienko">
<organization>Yandex</organization>
<address>
<postal>
<street>16, Leo Tolstoy St.</street>
<city>Moscow</city>
<region></region>
<code>119021</code>
<country>Russia</country>
</postal>
<email>infrastation@yandex.ru</email>
</address>
</author>
<date year="2014" />
<keyword>routing protocol</keyword>
<keyword>authentication</keyword>
<keyword>applied cryptography</keyword>
<abstract>
<t>This document describes a cryptographic authentication mechanism for Babel
routing protocol, updating, but not superseding RFC 6126. The mechanism
allocates two new TLV types for the authentication data, uses HMAC and is
both optional and backward compatible.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>[RFC Editor: before publication please remove the sentence below.]
Comments are solicited and should be addressed to the author.</t>
<t>Authentication of routing protocol exchanges is a common mean of
securing computer networks. 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.</t>
<t><xref target="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.</t>
<t>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.</t>
<t>The currently established (see <xref target="RIP2-AUTH" />,
<xref target="OSPF2-AUTH" />, <xref target="OSPF3-AUTH" />, <xref target="ISIS-AUTH-A" />, and
<xref target="RFC6039" />) approach to 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:
<list style="symbols">
<t>A fixed-length unsigned integer, typically called a
cryptographic sequence number, used in replay attack protection.</t>
<t>A variable-length sequence of octets, a result of the HMAC construct
(see <xref target="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.</t>
</list>
Depending on the design specifics either all protocol packets are
authenticated or only those protecting the integrity of protocol exchange.
This mechanism authenticates all protocol packets.</t>
<t>Although the HMAC construct is just one of many possible approaches to
cryptographic authentication of packets, this mechanism makes use of relevant
prior experience by using HMAC too 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 future extension.</t>
<t>This specification defines the use of the cryptographic sequence number
in details sufficient to make replay attack protection strength
predictable. That is, an operator can tell the strength from the declared
characteristics of an implementation and, whereas the implementation allows
to change relevant parameters, the effect of a reconfiguration.</t>
<t>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, e.g., L2TPv3 allows for 1 or 2 (<xref target="RFC3931" />
Section 5.4.1) and MANET protocols allow for several (<xref target="RFC7183" />
Section 6.1) results per authenticated packet.</t>
<t>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 the number of keys multiplied by the number of
supplied HMAC results (in the receiving case).</t>
<t>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.</t>
<t>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 CLI, or a management protocol
such as SNMP, or an inter-process communication mean such as a local socket,
or a combination of these.</t>
<section title="Requirements Language">
<t>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 <xref target="RFC2119">
BCP 14</xref>.</t>
</section>
</section>
<section title="Cryptographic Aspects">
<section anchor="hashalgos" title="Mandatory-to-Implement and Optional Hash Algorithms">
<t><xref target="RFC2104" /> defines HMAC as a construct 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.</t>
<t>Section 4.5 of <xref target="RFC6709" /> suggests selecting
one hash algorithm as mandatory-to-implement for the purpose of global
interoperability (Section 3.2 ibid.) 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 hash
algorithms mandatory-to-implement, unambiguously defined and generally
available in multiple implementations each.</t>
<t>An implementation of this mechanism MUST include support for two hash
algorithms:
<list style="symbols">
<t>RIPEMD-160 (160-bit digest)</t>
<t>SHA-1 (160-bit digest)</t>
</list></t>
<t>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 <xref target="padding" />). Implementors SHOULD
consider strong,
well-known hash algorithms as additional implementation options and MUST
NOT consider hash algorithms for that by the time of implementation
meaningful attacks exist or that are commonly viewed as deprecated.</t>
<t>In the latter case it is important to take into account considerations
both common (such as those made in <xref target="RFC4270" />) and specific
to the HMAC application of the hash algorithm. E.g., <xref target="RFC6151" />
considers MD5 collisions and concludes that new protocol designs should
not use HMAC-MD5, while <xref target="RFC6194" /> includes a comparable
analysis of SHA-1 that finds HMAC-SHA-1 secure for the same purpose.</t>
<t>For
example, the following hash algorithms meet these requirements at the time
of this writing (in alphabetical order):
<list style="symbols">
<t>GOST R 34.11-94 (256-bit digest)</t>
<t>SHA-224 (224-bit digest, SHA-2 family)</t>
<t>SHA-256 (256-bit digest, SHA-2 family)</t>
<t>SHA-384 (384-bit digest, SHA-2 family)</t>
<t>SHA-512 (512-bit digest, SHA-2 family)</t>
<t>Tiger (192-bit digest)</t>
<t>Whirlpool (512-bit digest, 2nd rev., 2003)</t>
</list>
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 construct, an implementation
MUST deny a use of such keys.</t>
</section>
<section anchor="padding" title="Definition of Padding">
<t>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. Specific
padding procedure of this mechanism addresses the following needs:
<list style="symbols">
<t>Data Initialization<vspace blankLines="1" />
A design that places the HMAC result(s) computed for a message inside
the same message after the computation has to allocate in the message
some data unit(s) purposed for the result(s) (in this mechanism it is
the HMAC TLV(s), see <xref target="hmac_tlv" />). The padding procedure
sets respective octets of the data unit(s), in the simplest case to a
fixed value known as the padding constant.
<vspace blankLines="1" />
Particular value of the constant is specific to each design. For
instance, in <xref target="RIP2-AUTH" /> as well as works derived from
it (<xref target="ISIS-AUTH-B" />, <xref target="OSPF2-AUTH" />, and
<xref target="OSPF3-AUTH" />) the value is 0x878FE1F3. In many other
designs (for instance, <xref target="RFC3315" />,
<xref target="RFC3931" />, <xref target="RFC4030" />,
<xref target="RFC4302" />, <xref target="RFC5176" />, and
<xref target="ISIS-AUTH-A" />) the value is 0x00.
<vspace blankLines="1" />
However, the HMAC construct is defined on the base of a cryptographic
hash algorithm, that is, an algorithm meeting 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 construct respectively.</t>
<t>Source Address Protection<vspace blankLines="1" />
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.
<vspace blankLines="1" />
In Babel the source address may be used as a prefix hext hop (see Section
3.5.3 of <xref target="BABEL" />). A well-known (see Section 2.3 of
<xref target="OSPF3-AUTH" />) 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 exchange of protocol packets using both IPv4 and IPv6
datagrams (see Section 4 of <xref target="BABEL" />). Even though in the
case of IPv6 exchange a Babel speaker currently uses only link-local
source addresses (Section 3.1 ibid.), 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.
<vspace blankLines="1" />
This procedure does not protect the destination address, which is
currently considered meaningless (ibid.) 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 into the protocol
packet (see <xref target="encjust" />).
</t>
</list></t>
<t>Description of the padding procedure:
<list style="numbers">
<t>Set the first 16 octets of the Digest field of the given HMAC TLV
to:
<list style="symbols">
<t>the given source address, if it is an IPv6 address, or</t>
<t>the IPv4-mapped IPv6 address (per Section 2.5.5.2 of
<xref target="RFC4291" />) holding the given source address, if
it is an IPv4 address.</t>
</list>
</t>
<t>Set the remaining (TLV Length - 18) octets of the Digest field of
the given HMAC TLV to 0x00.</t>
</list>
</t>
<t>For an example of a Babel packet with padded HMAC TLVs see
<xref target="sample_padded" />.</t>
</section>
<section anchor="cryptoseqno" title="Cryptographic Sequence Number Specifics">
<t>Operation of this mechanism may involve multiple local and multiple
remote cryptographic sequence numbers, each essentially being a 48&nbhy;bit
unsigned integer. This specification uses a term "TS/PC number" to avoid
confusion with the route's (Section 2.5 of <xref target="BABEL" />) or
node's (Section 3.2.1 ibid.) sequence numbers of the original Babel
specification and to stress the
fact that there are two distinguished parts of this 48&nbhy;bit number, each
handled in its specific way (see <xref target="tspcmgmt" />):</t>
<figure>
<artwork align="left">
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 |
+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//
</artwork>
<postamble>The high-order 32 bits are called "timestamp" (TS) and the low-order
16 bits are called "packet counter" (PC).</postamble>
</figure>
<t>This mechanism stores, updates, compares, and encodes each TS/PC number
as two independent unsigned integers, TS and PC respectively. Such
comparison of TS/PC numbers performed in item 3 of
<xref target="rx_procedure" /> is algebraically equivalent to comparison
of respective 48&nbhy;bit unsigned integers. Any byte order conversion, when
required, is performed on TS and PC parts independently.</t>
</section>
<section anchor="hmac" title="Definition of HMAC">
<t>The algorithm description below uses the following nomenclature, which
is consistent with <xref target="FIPS-198"></xref>:
<list style="hanging" hangIndent="7">
<t hangText="Text">Is the data on which the HMAC is calculated (note item
(b) of <xref target="security" />). 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 <xref target="BABEL" />
(see <xref target="datagram_structure" />).</t>
<t hangText="H">Is the specific hash algorithm (see
<xref target="hashalgos" />).</t>
<t hangText="K">Is a sequence of octets of an arbitrary, known length.</t>
<t hangText="Ko">Is the cryptographic key used with the hash algorithm.</t>
<t hangText="B">Is the block size of H, measured in octets rather than
bits. Note that B is the internal block size, not the digest length.</t>
<t hangText="L">Is the digest length of H, measured in octets rather than
bits.</t>
<t hangText="XOR">Is the bitwise exclusive-or operation.</t>
<t hangText="Opad">Is the hexadecimal value 0x5C repeated B times.</t>
<t hangText="Ipad">Is the hexadecimal value 0x36 repeated B times.</t>
</list></t>
<t>The algorithm below is the original, unmodified HMAC construct as
defined in both <xref target="RFC2104" /> and <xref target="FIPS-198" />,
hence it is different from the algorithms defined in
<xref target="RIP2-AUTH" />, <xref target="ISIS-AUTH-B" />, <xref target="OSPF2-AUTH" />, and
<xref target="OSPF3-AUTH" /> in exactly two regards:
<list style="symbols">
<t>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 handling of keys that have length greater than L but not
greater than B.</t>
<t>The algorithm below does not change value of Text before or after the
computation. Both padding of a Babel packet before the computation and
placing of the result inside the packet are performed elsewhere.</t>
</list>
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 construct coupled
with hash algorithms of choice are generally available.</t>
<t>Description of the algorithm:
<list style="numbers">
<t>Preparation of the Key<vspace blankLines="1" />
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.</t>
<t>First-Hash
<figure>
<preamble>A First-Hash, also known as the inner hash, is computed as
follows:</preamble>
<artwork align="center">
First-Hash = H(Ko XOR Ipad || Text)
</artwork>
</figure></t>
<t>Second-Hash
<figure>
<preamble>A second hash, also known as the outer hash, is computed as
follows:</preamble>
<artwork align="center">
Second-Hash = H(Ko XOR Opad || First-Hash)
</artwork>
</figure></t>
<t>Result<vspace blankLines="1" />
The resulting Second-Hash becomes the authentication data that is
returned as the result of HMAC calculation.</t>
</list>
</t>
<t>Note that in the case of Babel the Text parameter will never exceed
a few thousands of octets in length. In this specific case the optimization
discussed in Section 6 of <xref target="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).</t>
</section>
</section>
<section title="Updates to Protocol Data Structures">
<section anchor="RxAuthRequired" title="RxAuthRequired">
<t>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 to an authenticated Babel packet exchange and back (see
<xref target="migration" />). Current value of RxAuthRequired directly
affects the receiving procedure defined in <xref target="rx_procedure" />.
An implementation SHOULD allow the operator to change RxAuthRequired value
at runtime or by means of Babel speaker restart. An implementation MUST
allow the operator to discover the effective value of RxAuthRequired at
runtime or from the system documentation.</t>
</section>
<section title="LocalTS">
<t>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 <xref target="tspcmgmt" />.</t>
</section>
<section title="LocalPC">
<t>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 <xref target="tspcmgmt" />.</t>
</section>
<section anchor="mdi" title="MaxDigestsIn">
<t>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
(<xref target="rx_procedure" /> item 7) times for a given packet.</t>
<t>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 Babel speaker
restart. An implementation MUST allow the operator to discover the
effective value of MaxDigestsIn at runtime or from the system
documentation.</t>
</section>
<section anchor="mdo" title="MaxDigestsOut">
<t>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
(<xref target="tx_procedure" /> item 5) HMAC results to a given packet,
concurring with the output buffer management explained in
<xref target="buffering" />.</t>
<t>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 Babel speaker
restart, in a safe range. The maximum safe value of MaxDigestsOut is
implementation-specific (see <xref target="buffering" />). An
implementation MUST allow the operator to discover the effective value of
MaxDigestsOut at runtime or from the system documentation.</t>
</section>
<section anchor="anm_table" title="ANM Table">
<t>The ANM (Authentic Neighbours Memory) table resembles the neighbour
table defined in Section 3.2.3 of <xref target="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 purpose, field set and associated procedures are
different.</t>
<t>The conceptual purpose of the ANM table is to provide longer term replay
attack protection than it 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 Appendix A and Appendix B of
<xref target="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 ANM timeout parameter defined
in <xref target="anm_timeout" />) a copy of TS/PC number advertised in
authentic packets by each remote Babel speaker.</t>
<t>The ANM table is indexed by pairs of the form (Interface, Source). Every
table entry consists of the following fields:
<list style="symbols">
<t>Interface<vspace blankLines="1" />
An implementation-specific reference to the local node's interface that
the authentic packet was received through.</t>
<t>Source<vspace blankLines="1" />
The source address of the Babel speaker that the authentic packet was
received from.</t>
<t>LastTS<vspace blankLines="1" />
A 32-bit unsigned integer, the TS part of a remote TS/PC number.</t>
<t>LastPC<vspace blankLines="1" />
A 16-bit unsigned integer, the PC part of a remote TS/PC number.</t>
</list>
Each ANM table entry has an associated aging timer, which is reset by the
receiving procedure (<xref target="rx_procedure" /> item 9). If the timer
expires, the entry is deleted from the ANM table.</t>
<t>An implementation SHOULD use a persistent memory (NVRAM) to retain the
contents of 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 make it clear, if and how persistent
memory is used for ANM table. An implementation SHOULD allow the operator
to retrieve the current contents of ANM table at runtime. An implementation
SHOULD allow the operator to remove some or all of ANM table entries at
runtime or by means of Babel speaker restart.</t>
</section>
<section anchor="anm_timeout" title="ANM Timeout">
<t>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 standing
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.</t>
<t>In the first turn, implementations unable to maintain local TS/PC number
strictly increasing across Babel speaker restarts will reuse the advertised
TS/PC numbers after each restart (see <xref target="tspcmgmt" />). The
neighbouring speakers will treat the new packets as replayed and discard
them until the aging timer of respective ANM table entry expires or the
new TS/PC number exceeds the one stored in the entry.</t>
<t>Another possible, but less probable, case could be an environment
using IPv6 for Babel datagrams exchange and
involving physical moves of network interfaces hardware between Babel speakers.
Even performed without restarting the speakers, these 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.</t>
<t>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.</t>
<t>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 Babel
speaker restart. An implementation MUST allow the operator to discover the
effective value of ANM timeout at runtime or from the system documentation.</t>
</section>
<section anchor="csa" title="Configured Security Associations">
<t>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 ("interface's sequence of CSAs" hereafter). Each interface's
sequence of CSAs, as an integral part of the Babel
speaker configuration, MAY be intended for a 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 (<xref target="tx_procedure" /> item 1)
and the receiving (<xref target="rx_procedure" /> item 1) procedures
address this convention accordingly.</t>
<t>A single CSA structure consists of the following fields:
<list style="symbols">
<t>HashAlgo<vspace blankLines="1" />
An implementation-specific reference to one of the hash algorithms
supported by this implementation (see <xref target="hashalgos" />).</t>
<t>KeyChain<vspace blankLines="1" />
A finite sequence of elements ("KeyChain sequence" hereafter)
representing authentication keys, each element
being a structure consisting of the following fields:
<list style="symbols">
<t>LocalKeyID<vspace blankLines="1" />
An unsigned integer of an implementation-specific bit length.</t>
<t>AuthKeyOctets<vspace blankLines="1" />
A sequence of octets of an arbitrary, known length to be used as the
authentication key.</t>
<t>KeyStartAccept<vspace blankLines="1" />
The time that this Babel speaker will begin considering this
authentication key for accepting packets with authentication data.</t>
<t>KeyStartGenerate<vspace blankLines="1" />
The time that this Babel speaker will begin considering this
authentication key for generating packet authentication data.</t>
<t>KeyStopGenerate<vspace blankLines="1" />
The time that this Babel speaker will stop considering this
authentication key for generating packet authentication data.</t>
<t>KeyStopAccept<vspace blankLines="1" />
The time that this Babel speaker will stop considering this
authentication key for accepting packets with authentication data.</t>
</list></t>
</list></t>
<t>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), only a fraction of
the associated keys and hash algorithms may appear 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
<xref target="deriving" /> will be deterministically ordered as well.</t>
<t>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 if this requirement is or isn't met, the
implementation MUST provide a mean to discover the actual element order
used. Whichever order is used by an implementation, it MUST be preserved
across Babel speaker restarts.</t>
<t>Note that none of the CSA structure fields is constrained to contain
unique values. <xref target="sadup" /> explains this in more detail.
It is possible for the KeyChain sequence to be empty, although this is not
the intended manner of CSAs use.</t>
<t>The KeyChain sequence has a direct prototype, which is the "key chain"
syntax item of some existing router configuration languages. Whereas an
implementation already implements this syntax item, it is suggested to
reuse it, that is, to implement a CSA syntax item referring to a key
chain item instead of reimplementing the latter in full.</t>
</section>
<section anchor="esa" title="Effective Security Associations">
<t>An Effective Security Association (ESA) is a data structure immediately
used in sending (<xref target="tx_procedure" />) and receiving
(<xref target="rx_procedure" />) procedures. Its conceptual purpose is to
determine a runtime interface between those procedures and the deriving
procedure defined in <xref target="deriving" />. All ESAs are temporary
data units managed as elements of finite sequences that are not intended
for a persistent storage. Element ordering within each such finite sequence
("sequence of ESAs" hereafter) MUST be preserved as long as the sequence
exists.</t>
<t>A single ESA structure consists of the following fields:
<list style="symbols">
<t>HashAlgo<vspace blankLines="1" />
An implementation-specific reference to one of the hash algorithms
supported by this implementation (see <xref target="hashalgos" />).</t>
<t>KeyID<vspace blankLines="1" />
A 16-bit unsigned integer.</t>
<t>AuthKeyOctets<vspace blankLines="1" />
A sequence of octets of an arbitrary, known length to be used as the
authentication key.</t>
</list></t>
<t>Note that among the protocol data structures introduced by this
mechanism ESA is the only one not directly interfaced with the system
operator (see <xref target="dataflows" />), it is not immediately
present in the protocol encoding either. However, ESA is not just a
possible implementation technique, but an integral part of this
specification: the deriving (<xref target="deriving" />), the sending
(<xref target="tx_procedure" />), and the receiving
(<xref target="rx_procedure" />) procedures are defined in terms of the
ESA structure and its semantics provided herein. ESA is as meaningful for
a correct implementation as the other protocol data structures.</t>
</section>
</section>
<section title="Updates to Protocol Encoding">
<section anchor="encjust" title="Justification">
<t>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.</t>
<t>Considering existing implementations of 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 defined by Section 4.2 and Section 4.3 of
<xref target="BABEL" /> and further discussed in
<xref target="I-D.chroboczek-babel-extension-mechanism" />:
<list style="letters">
<t>A Babel packet consists of a four-octet header followed by a packet
body, that is, a sequence of TLVs (see
<xref target="datagram_structure" />). Besides the header and the
body, an actual Babel 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.</t>
<t>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. <xref target="BABEL" /> allocates TLV types 0 through
10 (see <xref target="tlv_namespace" />), defines 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) considering only the type (to distinguish between
a Pad1 TLV and any other TLV) and the length of each TLV, regardless if
and how many additional TLV types are eventually deployed.</t>
<t>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 PadN TLV) cannot be extended
with the extra data.</t>
</list></t>
<t>Considering each principal extension mean for the specific purpose of
adding authentication data items to each protocol packet, the following
arguments can be made:
<list style="symbols">
<t>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.</t>
<t>Use of the TLV extra data could also conflict with future developments
of the protocol encoding.</t>
<t>Since the packet trailing data is currently unstructured, using it
would involve defining an encoding structure and associated procedures,
adding to the complexity of both specification and implementation and
increasing the exposure to protocol attacks such as fuzzing.</t>
<t>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 multiplexing of data items belonging to
different extensions. Such a definition is out of the scope of this work.</t>
<t>Deprecating an extension (or only its protocol encoding) that uses
purely purpose-allocated TLVs is as simple as deprecating the TLVs.</t>
<t>Use of purpose-allocated TLVs is transparent for both the original
protocol and any its future extensions, regardless of the embedding
mean(s) used by the latter.</t>
</list></t>
<t>Considering all of the above, this mechanism neither uses the packet
trailing data nor uses 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
<xref target="tlv_namespace" />).</t>
</section>
<section title="TS/PC TLV">
<figure>
<preamble>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.
</preamble>
<artwork align="left">
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>Fields:
<list style="hanging" hangIndent="16">
<t hangText="Type">Set to 11 to indicate a TS/PC TLV.</t>
<t hangText="Length">The length in octets of the body, exclusive of the Type and
Length fields.</t>
<t hangText="PacketCounter">A 16-bit unsigned integer in network byte
order, the PC part of a TS/PC number stored in this TLV.</t>
<t hangText="Timestamp">A 32-bit unsigned integer in network byte
order, the TS part of a TS/PC number stored in this TLV.</t>
</list>
Note that the ordering of PacketCounter and Timestamp in the TLV structure is
opposite to the ordering of TS and PC in "TS/PC" term and the 48&nbhy;bit
equivalent (see <xref target="cryptoseqno" />).</t>
<t>Considering the "expected length" and the "extra data" in the definition
of Section 4.3 of <xref target="BABEL" />, the expected length of a TS/PC
TLV body is unambiguously defined as 6 octets. The receiving procedure
correctly processes any TS/PC TLV with body length not less than the
expected, ignoring any extra data (<xref target="rx_procedure" /> items
3 and 9). The sending procedure produces a TS/PC TLV with body length equal
to the expected and Length field set respectively
(<xref target="tx_procedure" /> item 3).</t>
<t>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 necessary adjustments to Length TLV field, "Body
length" packet header field and output buffer management explained in
<xref target="buffering" />.</t>
</section>
<section anchor="hmac_tlv" title="HMAC TLV">
<figure>
<preamble>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.
</preamble>
<artwork align="left">
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...
+-+-+-+-+-+-+-+-+-+-+-+-
</artwork>
</figure>
<t>Fields:
<list style="hanging" hangIndent="16">
<t hangText="Type">Set to 12 to indicate an HMAC TLV.</t>
<t hangText="Length">The length in octets of the body, exclusive of the Type and
Length fields.</t>
<t hangText="KeyID">A 16-bit unsigned integer in network byte order.</t>
<t hangText="Digest">A variable-length sequence of octets, which is at
least 16 octets long (see <xref target="padding" />).</t>
</list></t>
<t>Considering the "expected length" and the "extra data" in the definition
of Section 4.3 of <xref target="BABEL" />, the expected length of an HMAC
TLV body is not defined. The receiving and the padding procedures process
every octet of
the Digest field, deriving the field boundary from the Length field value
(<xref target="rx_procedure" /> item 7 and <xref target="padding" />
respectively). The sending procedure produces
HMAC TLVs with Length field precisely sizing the Digest field to match
digest length of the hash algorithm used (<xref target="tx_procedure" />
items 5 and 8).</t>
<t>The HMAC TLV structure defined herein is final, future Babel extensions MUST
NOT extend it with any extra data.</t>
</section>
</section>
<section title="Updates to Protocol Operation">
<section anchor="tspcmgmt" title="Per-Interface TS/PC Number Updates">
<t>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 mandatory for the advertised TS/PC number: its 48&nbhy;bit equivalent
(see <xref target="cryptoseqno" />)
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.</t>
<t>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 (<xref target="tx_procedure" /> item
2) before advertising the TS/PC number in a TS/PC TLV.</t>
<t>Depending on particular implementation method of these two updates the
advertised TS/PC number may possess additional properties improving the
replay attack protection strength. This includes, but is not limited to
the methods below.
<list style="letters">
<t>The most straightforward implementation would use LocalTS as a plain
wrap counter, defining the updates as follows:
<list style="hanging" hangIndent="16">
<t hangText="initialization">Set LocalPC to 0, set LocalTS to 0.</t>
<t hangText="increment">Increment LocalPC by 1. If LocalPC wraps
(0xFFFF + 1 = 0x0000), increment LocalTS by 1.</t>
</list>
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 <xref target="anm_table" /> and
<xref target="anm_timeout" />).</t>
<t>A more advanced implementation could make a use of any 32&nbhy;bit unsigned
integer timestamp (number of time units since an arbitrary epoch) such
as the UNIX timestamp, whereas 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:
<list style="hanging" hangIndent="16">
<t hangText="initialization">Set LocalPC to 0, set LocalTS to 0.</t>
<t hangText="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.</t>
</list>
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.</t>
<t>Another advanced implementation could use LocalTS in a way similar
to the "wrap/boot counter" suggested in Section 4.1.1 of
<xref target="OSPF3-AUTH" />, defining the updates as follows:
<list style="hanging" hangIndent="16">
<t hangText="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.</t>
<t hangText="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.</t>
</list>
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.</t>
</list></t>
<t>As long as the TS/PC number retains its mandatory property stated above,
it is up to the implementor, which TS/PC number updates methods are
available and if 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 documentation.
These requirements are necessary to enable the optimal (see
<xref target="anm_timeout" />) management of ANM timeout in a network
segment.</t>
<t>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.</t>
</section>
<section anchor="deriving" title="Deriving ESAs from CSAs">
<t>Neither receiving nor sending procedures work with the contents of
interface's sequence of CSAs directly, both (<xref target="rx_procedure" />
item 4 and <xref target="tx_procedure" /> item 4 respectively) derive a
sequence of ESAs from the sequence of CSAs and use the derived sequence (see
<xref target="dataflows" />). There are two
main goals achieved through this indirection:
<list style="symbols">
<t>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.</t>
<t>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 KeyChain sequence of each CSA. The particular
correlation maintained by this procedure implements a concept of fair
(independent of number of keys contained by each) competition between
CSAs.</t>
</list>
The deriving procedure uses the following input arguments:
<list style="symbols">
<t>input sequence of CSAs</t>
<t>direction (sending or receiving)</t>
<t>current time (CT)</t>
</list>
The processing of input arguments begins with an empty output sequence of
ESAs and consists of the following steps:
<list style="numbers">
<t>Make a temporary copy of the input sequence of CSAs.</t>
<t>Remove all expired authentication keys from each KeyChain sequence of the
copy, that is, any keys such that:
<list style="symbols">
<t>for receiving: KeyStartAccept is greater than CT or KeyStopAccept
is less than CT</t>
<t>for sending: KeyStartGenerate is greater than CT or KeyStopGenerate
is less than CT</t>
</list>
Note well that there are no special exceptions. Remove all expired keys,
even if there are no keys left after that (see
<xref target="exhaustion" />).</t>
<t>Use the copy to populate the output sequence of ESAs as follows:
<list style="numbers">
<t>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:
<list style="hanging" hangIndent="15">
<t hangText="HashAlgo">Set to HashAlgo of the current CSA.</t>
<t hangText="KeyID">Set to LocalKeyID modulo 2^16 of the current key
of the current CSA.</t>
<t hangText="AuthKeyOctets">Set to AuthKeyOctets of the current key
of the current CSA.</t>
</list>
Append this ESA to the end of the output sequence.</t>
<t>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.</t>
<t>When the KeyChain sequence of the first CSA contains at least two
keys, use its second key the same way.</t>
<t>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.</t>
<t>And so forth until all keys of all CSAs of the copy are processed,
exactly once each.</t>
</list>
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".</t>
<t>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.</t>
</list>
The resulting sequence will contain zero or more unique ESAs, ordered in a way
deterministically correlated with ordering of CSAs within the original
input sequence of CSAs and ordering of keys within each KeyChain sequence. This
ordering maximizes the probability of having 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
<xref target="derivingopts" />.</t>
</section>
<section anchor="tx_procedure" title="Updates to Packet Sending">
<t>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
<xref target="dataflows" />). After that send the packet regardless if the
authentication-specific processing modified the outgoing packet or left
it intact.
<list style="numbers">
<t>If the current outgoing interface's sequence of CSAs is empty, finish
authentication-specific processing and consider the packet ready for
sending.</t>
<t>Increment TS/PC number of the current outgoing interface as explained
in <xref target="tspcmgmt" />.</t>
<t>Add to the packet body (see the note at the end of this section) a
TS/PC TLV with fields set as follows:
<list style="hanging" hangIndent="16">
<t hangText="Type">Set to 11.</t>
<t hangText="Length">Set to 6.</t>
<t hangText="PacketCounter">Set to the current value of LocalPC
variable of the current outgoing interface.</t>
<t hangText="Timestamp">Set to the current value of LocalTS variable
of the current outgoing interface.</t>
</list>
Note that the current step may involve byte order conversion.</t>
<t>Derive a sequence of ESAs using procedure defined in
<xref target="deriving" /> 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.</t>
<t>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:
<list style="hanging" hangIndent="9">
<t hangText="Type">Set to 12.</t>
<t hangText="Length">Set to 2 plus digest length of HashAlgo of the
current ESA.</t>
<t hangText="KeyID">Set to KeyID of the current ESA.</t>
<t hangText="Digest">Size exactly equal to the digest length of HashAlgo of
the current ESA. Pad (see <xref target="padding" />) using the source
address of the current packet (see <xref target="srcaddr" />).</t>
</list>
As soon as there are MaxDigestsOut HMAC TLVs added to the current
packet body, immediately proceed to the next step.<vspace blankLines="1" />
Note that the current step may involve byte order conversion.</t>
<t>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.<vspace blankLines="1" />
Note that the current step may involve byte order conversion.</t>
<t>Make a temporary copy of the current packet.</t>
<t>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
<xref target="hmac" />) 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 <xref target="sample_results" />) of the current
packet (not the copy).</t>
<t>After this point, allow no more changes to the current packet header and body and
consider it ready for sending.</t>
</list></t>
<t>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 <xref target="exhaustion" />.</t>
<t>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.</t>
<t>For example, see <xref target="datagram_structure" />. 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.</t>
<t>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.</t>
</section>
<section anchor="rx_procedure" title="Updates to Packet Receiving">
<t>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 <xref target="dataflows" />).
The final action conceptually depends not only upon the result of the
authentication-specific processing, but also on the current value of
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).
<list style="numbers">
<t>If the current incoming interface's sequence of CSAs is empty, accept the
packet.</t>
<t>If the current packet does not contain exactly one TS/PC TLV, refuse it.</t>
<t>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 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:
<list style="symbols">
<t>Timestamp is less than LastTS</t>
<t>Timestamp is equal to LastTS and PacketCounter is not greater than
LastPC</t>
</list>
Note that the current step may involve byte order conversion.</t>
<t>Derive a sequence of ESAs using procedure defined in
<xref target="deriving" /> 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.</t>
<t>Make a temporary copy of the current packet.</t>
<t>Pad (see <xref target="padding" />) every HMAC TLV present in the
temporary copy (not the original packet) using the source address of the
original packet.</t>
<t>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 digest length of
HashAlgo of the ESA is equal to Length of the TLV and KeyID of the ESA
is equal to 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.
<vspace blankLines="1" />
For each of these ESAs compute an HMAC result (see <xref target="hmac" />)
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 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.<vspace blankLines="1" />
Note that the current step may involve byte order conversion.</t>
<t>Refuse the input packet unless there was a matching HMAC result in
the previous step.</t>
<t>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.<vspace blankLines="1" />
Note that the current step may involve byte order conversion.</t>
<t>Accept the input packet.</t>
</list>
An implementation SHOULD before the authentication-specific processing
above perform those basic procedures of the original protocol that don't
take any protocol actions upon the contents of the packet but discard it
unless the packet is sufficiently well-formed for further processing.
Although 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 if any authentication-specific processing is
due, unless its source address conforms to Section 3.1 of
<xref target="BABEL" /> and is not the receiving speaker's own address
(see item (e) of <xref target="security" />).</t>
<t>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 counters 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 (<xref target="migration" />)
implementation.</t>
</section>
<section anchor="stats" title="Authentication-Specific Statistics Maintenance">
<t>A Babel speaker implementing this mechanism SHOULD maintain a set of
counters for the following events, per protocol instance and per
interface:
<list style="letters">
<t>Sending of an unauthenticated Babel packet through an interface having
an empty sequence of CSAs (<xref target="tx_procedure" /> item 1).</t>
<t>Sending of an unauthenticated Babel packet with a TS/PC TLV but
without any HMAC TLVs due to an empty derived sequence of ESAs
(<xref target="tx_procedure" /> item 4).</t>
<t>Sending of an authenticated Babel packet containing both TS/PC and
HMAC TLVs (<xref target="tx_procedure" /> item 9).</t>
<t>Accepting of a Babel packet received through an interface having an
empty sequence of CSAs (<xref target="rx_procedure" /> item 1).</t>
<t>Refusing of a received Babel packet due to an empty derived sequence
of ESAs (<xref target="rx_procedure" /> item 4).</t>
<t>Refusing of a received Babel packet that does not contain exactly one TS/PC TLV
(<xref target="rx_procedure" /> item 2).</t>
<t>Refusing of a received Babel packet due to the TS/PC TLV
failing the ANM table check (<xref target="rx_procedure" /> item 3). In
the view of future extensions this event SHOULD leave out some small
amount, per current (Interface, Source, LastTS, LastPC) tuple, of the
packets refused due to Timestamp value being equal to LastTS and
PacketCounter value being equal to LastPC.</t>
<t>Refusing of a received Babel packet missing any HMAC TLVs
(<xref target="rx_procedure" /> item 8).</t>
<t>Refusing of a received Babel packet due to none of the processed
HMAC TLVs passing the ESA check (<xref target="rx_procedure" /> item 8).</t>
<t>Accepting of a received Babel packet having both TS/PC and HMAC TLVs
(<xref target="rx_procedure" /> item 10).</t>
<t>Delivery of a refused packet to the instance of the original
protocol due to RxAuthRequired parameter set to FALSE.</t>
</list>
Note that 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 counters readings SHOULD be available to the
operator at runtime.</t>
</section>
</section>
<section title="Implementation Notes">
<section anchor="srcaddr" title="Source Address Selection for Sending">
<t>Section 3.1 of <xref target="BABEL" /> allows for exchange of protocol
datagrams using IPv4 or 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 addresses
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
(<xref target="tx_procedure" /> item 5) exact knowledge of packet source
address for proper padding of HMAC TLVs.</t>
<t>As long as a network interface has more than one addresses 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 make this choice to both the sending procedure and the network stack (see
<xref target="dataflows" />). 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.</t>
</section>
<section anchor="buffering" title="Output Buffer Management">
<t>An instance of the original protocol buffers 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 <xref target="BABEL" />).</t>
<t>Since TS/PC and HMAC TLVs and any other TLVs, in the first place those
of the original protocol, share the same packet space (see
<xref target="datagram_structure" />) and respectively the same buffer
space, a particular portion of each interface buffer needs to be reserved
for 1 TS/PC TLV and up to MaxDigestsOut HMAC TLVs. The amount (R) of this
reserved buffer space is calculated as follows:</t>
<figure>
<artwork align="center">
R = St + MaxDigestsOut * Sh =
= 8 + MaxDigestsOut * (4 + Lmax)
</artwork>
</figure>
<t><list style="hanging" hangIndent="8">
<t hangText="St">Is the size of a TS/PC TLV.</t>
<t hangText="Sh">Is the size of an HMAC TLV.</t>
<t hangText="Lmax">Is the maximum digest length in octets possible for
a particular interface. It SHOULD be calculated based on particular
interface's sequence of CSAs, but MAY be taken as the maximum digest length
supported by particular implementation.</t>
</list></t>
<t>An implementation allowing for per-interface value of MaxDigestsOut
or Lmax has to account for different value of R across different
interfaces, even having the same MTU. An implementation allowing for
runtime change of the value of R (due to MaxDigestsOut or Lmax) has to
take care of the TLVs already buffered by the time of the change,
especially when the value of R increases.</t>
<t>The maximum safe value of MaxDigestsOut parameter depends on the
interface MTU and maximum digest length used. In general, at least 200-300
octets of a Babel packet should be always available to data other than
TS/PC and HMAC TLVs. An implementation following the requirements of
Section 4 of <xref target="BABEL" /> would send packets sized 512 octets
or larger. If, for example, the maximum digest length is 64 octets and
MaxDigestsOut value is 4, the value of R would be 280, leaving less than
a half of a 512-octet packet for any other TLVs. As long as the interface MTU
is larger or digest length is smaller, higher values of MaxDigestsOut can
be used safely.</t>
</section>
<section anchor="derivingopts" title="Optimizations of ESAs Deriving">
<t>The following optimizations of the ESAs deriving procedure can reduce
amount of CPU time consumed by authentication-specific processing,
preserving an implementation's effective behaviour.
<list style="letters">
<t>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.
<vspace blankLines="1" />
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 both none of the active keys expire and none
of the inactive keys enter into operation.<vspace blankLines="1" />
An implementation optimized 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.</t>
<t>Considering that the sending procedure iterates over at most
MaxDigestsOut elements of the derived sequence of ESAs
(<xref target="tx_procedure" /> item 5), there would be little sense in
the case of "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 "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.</t>
</list></t>
</section>
<section anchor="sadup" title="Security Associations Duplication">
<t>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 CSA structure
fields (including HashAlgo, LocalKeyID, and AuthKeyOctets) alone or in a
combination has to be unique within a given CSA, or within a given sequence
of CSAs, or within all sequences of CSAs of a Babel speaker.</t>
<t>In the CSA space defined this way, for any two authentication keys their
one field (in)equality would not imply their 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 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 (<xref target="deriving" /> item 4).</t>
<t>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.</t>
<t>Furthermore, if in this situation the operator decided to migrate one
of the domains to a different LocalKeyID value in a seamless way, 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 <xref target="security" />). This would make a similar use
case.</t>
<t>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 respective
reasoning made in Section 3.1 of <xref target ="RIP2-AUTH" /> still
applies). This way the
additional key management constraints, if any, would remain out of scope
of this authentication mechanism. A similar thinking justifies LocalKeyID
field having bit length in ESA structure definition, but not in that of
CSA.</t>
</section>
</section>
<section title="Network Management Aspects">
<section title="Backward Compatibility">
<t>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
would not distribute routing information uni-directionally or form a
routing loop or experience other protocol logic issues specific purely to
the use of this mechanism.</t>
<t>The Babel design requires a bi-directional neighbour reachability condition
between two given speakers for a successful exchange of routing information.
Apparently, in the case above neighbour reachability would be
uni-directional. Presence of TS/PC and HMAC TLVs in Babel packets sent by
A would be transparent to B. But lack of authentication data in Babel
packets send by B would make them effectively invisible to the instance
of the original protocol of A. Uni-directional links are not specific to
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
<xref target="BABEL" />).</t>
</section>
<section title="Multi-Domain Authentication">
<t>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.</t>
<t>For example, consider three Babel speakers with one interface each,
configured with the following CSAs:
<list style="symbols">
<t>speaker A: (hash algorithm H1; key SK1), (hash algorithm H1; key SK2)</t>
<t>speaker B: (hash algorithm H1; key SK1)</t>
<t>speaker C: (hash algorithm H1; key SK2)</t>
</list>
Packets sent by A would contain 2 HMAC TLVs each, packets sent by B and
C would contain 1 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.</t>
<t>Consider a similar set of speakers configured with different CSAs:
<list style="symbols">
<t>speaker D: (hash algorithm H2; key SK3), (hash algorithm H3; key SK4)</t>
<t>speaker E: (hash algorithm H2; key SK3), (hash algorithm H4, keys SK5
and SK6)</t>
<t>speaker F: (hash algorithm H3; keys SK4 and SK7), (hash algorithm H5,
key SK8)</t>
</list>
Packets sent by D would contain 2 HMAC TLVs each, packets sent by E and
F would contain 3 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 use of SK7, H5, and SK8 by F (for their own purposes) would
remain insignificant to A.</t>
<t>An operator implementing a 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 <xref target="mdi" /> and
<xref target="mdo" />), when more than 2 authentication domains are
configured simultaneously it is advised to confirm that every involved
speaker can handle sufficient number of HMAC results for both sending and
receiving.</t>
<t>The recommended method of Babel speaker configuration for multi-domain
authentication is not only using a different authentication key for each
domain, but also using 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 <xref target="security" />.</t>
</section>
<section anchor="migration" title="Migration to and from Authenticated Exchange">
<t>It is common in practice to consider a migration to authenticated
exchange of routing information only after the network has already been
deployed and put to an 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 <xref target="RxAuthRequired" />. This
measure is similar to the "transition mode" suggested in Section 5 of
<xref target="OSPF3-AUTH" />.</t>
<t>An operator performing the migration needs to arrange configuration
changes as follows:
<list style="numbers">
<t>Decide on particular hash algorithm(s) and key(s) to be used.</t>
<t>Identify all speakers and their involved interfaces that need to be
migrated to authenticated exchange.</t>
<t>For each of the speakers and the interfaces to be reconfigured first
set RxAuthRequired parameter to FALSE, then configure necessary CSA(s).</t>
<t>Examine the speakers to confirm that Babel packets are successfully
authenticated according to the configuration (supposedly, through
examining ANM table entries and authentication-specific statistics, see
<xref target="dataflows" />) and address any discrepancies before
proceeding further.</t>
<t>For each of the speakers and the reconfigured interfaces set the
RxAuthRequired parameter to TRUE.</t>
</list>
Likewise, temporarily setting RxAuthRequired to FALSE can be used to
migrate smoothly from an authenticated packet exchange back to unauthenticated
one.</t>
</section>
<section anchor="exhaustion" title="Handling of Authentication Keys Exhaustion">
<t>This specification employs a common concept of multiple authenticaion
keys co-existing for a given interface, with two independent lifetime
ranges associated with each key (one for sending and another for
receiving). It is typically recommended to configure the keys 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 or receiving or both). Possible ways of addressing this situation
raise their own concerns:
<list style="symbols">
<t>Automatic switching to unauthenticated protocol exchange. This
behaviour invalidates the initial purposes of authentication and is
commonly viewed as "unacceptable" (<xref target="RIP2-AUTH" /> Section 5.1,
<xref target="OSPF2-AUTH" /> Section 3.2, <xref target="OSPF3-AUTH" />
Section 3, <xref target="OSPF3-AUTH-BIS" /> Section 3).</t>
<t>Stopping routing information exchange over the interface. This
behaviour is likely to impact regular traffic routing and is commonly
viewed as "not advisable" (<xref target="RIP2-AUTH" />,
<xref target="OSPF2-AUTH" />, <xref target="OSPF3-AUTH" />), although
<xref target="OSPF3-AUTH-BIS" /> is different in this regard.</t>
<t>Use of the "most recently expired" key over its intended lifetime
range. This behaviour is recommended for implementation in
<xref target="RIP2-AUTH" />, <xref target="OSPF2-AUTH" />,
<xref target="OSPF3-AUTH" />, but not in <xref target="OSPF3-AUTH-BIS" />.
The use may become a problem due to an offline cryptographic attack
(see item (f) of <xref target="security" />) or a compromise of the
key. In addition, telling a recently expired key from a key never ever
been in a use may be impossible after a router restart.</t>
</list>
Design of this mechanism prevents the 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 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
<xref target="RIP2-AUTH" />).</t>
<t>Although the deriving procedure does not allow for any exceptions in
expired keys filtering (<xref target="deriving" /> 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 more preferred than 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.</t>
</section>
</section>
<section title="Implementation Status">
<t>[RFC Editor: before publication please remove this section and the
reference to <xref target="RFC6982" />, along the offered
experiment of which this section exists to assist document reviewers.]</t>
<t>At the time of this writing the original Babel protocol is available in
two free, production-quality implementations, both of which support IPv4 and
IPv6 routing but exchange Babel packets using IPv6 only:
<list style="symbols">
<t>The "standalone" babeld, a BSD-licensed software with source code
<eref target="https://github.com/jech/babeld">publicly available</eref>.
<vspace blankLines="1" />
That implementation does not support this authentication mechanism.</t>
<t>The integrated babeld component of Quagga-RE, a work derived from Quagga
routing protocol suite, a GPL-lisensed software with source code
<eref target="https://github.com/Quagga-RE/quagga-RE">publicly available</eref>.
<vspace blankLines="1" />
That implementation supports this authentication mechanism as defined in
revision 09 of this document. It supports both mandatory-to-implement hash
algorithms (RIPEMD-160 and SHA-1) and a few additional algorithms (SHA-224,
SHA-256, SHA-384, SHA-512 and Whirlpool). It does not support more than
one link-local IPv6 address per interface. It does not distinguish refused
replayed packets for purpose of logging in the sense of item (g) of
<xref target="stats" /> and does not check the packet source address before
the authentication-specific processing as suggested in
<xref target="rx_procedure" />. It implements
authentication-specific parameters, data structures and methods as follows
(whether a parameter can be "changed at runtime", it is done by means of CLI
and can also be set in a configuration file):
<list style="symbols">
<t>MaxDigestsIn value is fixed to 4.</t>
<t>MaxDigestsOut value is fixed to 4.</t>
<t>RxAuthRequired value is specific to each interface and can be changed
at runtime.</t>
<t>ANM Table contents is not retained across speaker restarts, can be
retrieved and reset (all entries at once) by means of CLI.</t>
<t>ANM Timeout value is specific to the whole protocol instance, has a
default value of 300 seconds and can be changed at runtime.</t>
<t>Ordering of elements within each interface's sequence of CSAs is
arbitrary as set by operator at runtime. CSAs are implemented to refer
to existing key chain syntax items. Elements of an interface's sequence
of CSAs are constrained to be unique reference-wise, but not
contents-wise, that is, it is possible to duplicate security associations
using a different key chain name to contain the same keys.</t>
<t>Ordering of elements within each KeyChain sequence is fixed to the sort
order of LocalKeyID. LocalKeyID is constrained to be unique within each
KeyChain sequence.</t>
<t>TS/PC number updates method can be configured at runtime for the whole
protocol instance to one of two methods standing for items (a) and (b) of
<xref target="tspcmgmt" />. The default method is (b).</t>
<t>Most of the authentication-specific statistics counters listed in
<xref target="stats" /> are implemented (per protocol instance and per
each interface) and their readings are available
by means of CLI with an option to log respective events into a file.</t>
</list>
No other implementations of this authentication mechanism are known to
exist, thus interoperability can only be assessed on paper. The only existing
implementation has been tested to be fully compatible with itself
regardless of a speaker CPU endianness.</t>
</list></t>
</section>
<section anchor="security" title="Security Considerations">
<t>Use of this mechanism implies requirements common to a use of shared
authentication keys, including, but not limited to:
<list style="symbols">
<t>holding the keys secret,</t>
<t>including sufficient amounts of random bits into each key,</t>
<t>rekeying on a regular basis, and</t>
<t>never reusing a used key for a different purpose</t>
</list>
That said, proper design and implementation of a key management policy is
out of scope of this work. Many publications on this subject exist and
should be used for this purpose (<xref target="RFC4107">BCP 107</xref>,
<xref target="RFC4962">BCP 132</xref>, and <xref target="RFC6039" /> may be suggested as
starting points).</t>
<t>It is possible for a network that exercises authentication keys rollover
to experience accidental expiration of all the keys for a network interface
as discussed at greater length in <xref target="exhaustion" />. With that
and the guidance of Section 5.1 of <xref target="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 the item (b) of <xref target="stats" />.
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.</t>
<t>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:
<list style="format %c." counter="secitems">
<t>Peer Entity Authentication<vspace blankLines="1" />
The Babel speaker authentication mechanism defined herein is believed to be
as strong as is the class itself that it belongs to. This specification
is built on fundamental concepts implemented for authentication of
similar routing protocols: per-packet authentication, use of HMAC
construct, 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.</t>
<t>Data Integrity<vspace blankLines="1" />
Meaningful parts of a Babel datagram are the contents of the Babel packet
(in the definition of Section 4.2 of <xref target="BABEL" />) and the
source address of the datagram (Section 3.5.3 ibid.). This mechanism
authenticates both parts using the HMAC construct, 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 construct itself or
successfully recovering the authentication key.<vspace blankLines="1" />
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 respectively 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
<xref target="datagram_structure" />).</t>
<t>Denial of Service<vspace blankLines="1" />
Proper deployment of this mechanism in a Babel network significantly increases
the efforts required for an attacker to feed arbitrary Babel PDUs into
protocol exchange (with an intent of attacking a particular Babel speaker
or disrupting exchange of regular traffic in a routing domain). It also
protects the neighbour table from being flooded with forged speaker
entries.<vspace blankLines="1" />
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.</t>
<t>Reflection Attacks<vspace blankLines="1" />
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
<xref target="rx_procedure" />.</t>
</list>
The following in-scope concern is only partially addressed:
<list style="format %c." counter="secitems">
<t>Replay Attacks<vspace blankLines="1" />
This specification establishes a basic replay protection measure (see
<xref target="anm_table" />), defines a timeout parameter affecting its
strength (see <xref target="anm_timeout" />), and outlines implementation
methods also affecting protection strength in several ways (see
<xref target="tspcmgmt" />). 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.<vspace blankLines="1" />
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 bi-directional
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.
<vspace blankLines="1" />
A reliable solution to this particular problem, which Section 4.5 of
<xref target="RFC7186" /> discusses as well, is not currently known. It
is recommended that the operators use distinct CSAs for distinct network
segments.</t>
</list>
The following in-scope concerns are not addressed:
<list style="format %c." counter="secitems">
<t>Offline Cryptographic Attacks<vspace blankLines="1" />
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 got all
the parameters of the authentication-specific processing performed by the
sender, except authentication key(s) and 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, complexity of this attack
is essentially that of the authentication key attack.<vspace blankLines="1" />
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 use of strong keys
with a sufficient number of random bits.<vspace blankLines="1" />
It is important to understand that in the case of multiple keys being used
within single interface (for a 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.<vspace blankLines="1" />
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 (<xref target="deriving" /> item 4), but
an HMAC result computed for a given packet will be the same for each of
these keys. In the case of sending procedure this can produce multiple HMAC
TLVs with exactly the same value of the Digest field, but different values
of KeyID field. In this case the attacker will see that the keys are the
same, even without the knowledge of the key itself. Reuse of authentication
keys is not the intended use case of this mechanism and should be strongly
avoided.</t>
<t>Non-repudiation<vspace blankLines="1" />
This specification relies on a use of shared keys. There is no timestamp
infrastructure and no key revocation mechanism defined to address a shared
key compromise. 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 with the shared key
not being compromised, reliably identifying the speaker that had actually
sent a given authentic Babel packet is not possible any better than proving
the speaker belongs to the group sharing the key (any of the speakers
sharing a key can impose any other speaker sharing the same key).</t>
<t>Confidentiality Violations<vspace blankLines="1" />
The original Babel protocol does not encrypt any of the information
contained in its packets. The contents of a Babel packet is trivial to decode,
revealing 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 WPA2 at the time of this writing.</t>
<t>Key Management<vspace blankLines="1" />
Any authentication key exchange/distribution concerns are left out of
scope. However, the internal representation of authentication keys (see
<xref target="csa" />) allows for diverse key management means, manual
configuration in the first place.</t>
<t>Message Deletion<vspace blankLines="1" />
Any message deletion attacks are left 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, the currently established
practice is treating authentication purely as a per-packet function without
any added detection of lost packets.</t>
</list></t>
</section>
<section title="IANA Considerations">
<t>[RFC Editor: please do not remove this section.]</t>
<t>At the time of this publication Babel TLV Types namespace did not have
an IANA registry. TLV types 11 and 12 were assigned
(see <xref target="tlv_namespace" />) to the TS/PC and HMAC
TLV types by Juliusz Chroboczek, designer of the original Babel protocol.
Therefore, this document has no IANA actions.</t>
</section>
<section title="Acknowledgements">
<t>Thanks to Randall Atkinson and Matthew Fanto for their comprehensive work on
<xref target="RIP2-AUTH" /> that initiated a series of publications on
routing protocols authentication, including this one. This specification
adopts many concepts belonging to the whole series.</t>
<t>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.</t>
<t>Thanks to Joel Halpern, Jim Schaad, Randall Atkinson, and Stephen Farrell
for providing (in chronological order) valuable feedback on draft versions
of this document.</t>
<t>Thanks to Jim Gettys and Dave Taht for developing CeroWrt wireless router
project and collaborating on many integration issues. A practical need for
Babel authentication emerged during a research based on CeroWrt that
eventually became the very first use case of this mechanism.</t>
<t>Thanks to Kunihiro Ishiguro and Paul Jakma for establishing 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 base of Quagga and Libgcrypt.</t>
<t>This document was produced using the xml2rfc
(<xref target="RFC2629" />) authoring tool.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2104.xml"?>
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.4291.xml"?>
<reference anchor="FIPS-198">
<front>
<title>The Keyed-Hash Message Authentication Code (HMAC)</title>
<author>
<organization>US National Institute of Standards & Technology</organization>
</author>
<date month="July" year="2008" />
</front>
<seriesInfo name="FIPS PUB" value="198-1" />
</reference>
<reference anchor="BABEL">
<front>
<title>The Babel Routing Protocol</title>
<author initials="J." surname="Chroboczek" fullname="J. Chroboczek"></author>
<date year="2011" month="April" />
</front>
<seriesInfo name="RFC" value="6126" />
</reference>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2629.xml"?>
<?rfc include="reference.RFC.3315.xml"?>
<?rfc include="reference.RFC.3931.xml"?>
<?rfc include="reference.RFC.4030.xml"?>
<?rfc include="reference.RFC.4107.xml"?>
<?rfc include="reference.RFC.4270.xml"?>
<?rfc include="reference.RFC.4302.xml"?>
<reference anchor="RIP2-AUTH">
<front>
<title>RIPv2 Cryptographic Authentication</title>
<author initials="R." surname="Atkinson" fullname="R. Atkinson"></author>
<author initials="M." surname="Fanto" fullname="M. Fanto"></author>
<date year="2007" month="February" />
</front>
<seriesInfo name="RFC" value="4822" />
</reference>
<?rfc include="reference.RFC.4962.xml"?>
<?rfc include="reference.RFC.5176.xml"?>
<reference anchor="ISIS-AUTH-A">
<front>
<title>IS-IS Cryptographic Authentication</title>
<author initials="T." surname="Li" fullname="T. Li"></author>
<author initials="R." surname="Atkinson" fullname="R. Atkinson"></author>
<date year="2008" month="October" />
</front>
<seriesInfo name="RFC" value="5304" />
</reference>
<reference anchor="ISIS-AUTH-B">
<front>
<title>IS-IS Generic Cryptographic Authentication</title>
<author initials="M." surname="Bhatia" fullname="M. Bhatia"></author>
<author initials="V." surname="Manral" fullname="V. Manral"></author>
<author initials="T." surname="Li" fullname="T. Li"></author>
<author initials="R." surname="Atkinson" fullname="R. Atkinson"></author>
<author initials="R." surname="White" fullname="R. White"></author>
<author initials="M." surname="Fanto" fullname="M. Fanto"></author>
<date year="2009" month="February" />
</front>
<seriesInfo name="RFC" value="5310" />
</reference>
<reference anchor="OSPF2-AUTH">
<front>
<title>OSPFv2 HMAC-SHA Cryptographic Authentication</title>
<author initials="M." surname="Bhatia" fullname="M. Bhatia"></author>
<author initials="V." surname="Manral" fullname="V. Manral"></author>
<author initials="M." surname="Fanto" fullname="M. Fanto"></author>
<author initials="R." surname="White" fullname="R. White"></author>
<author initials="M." surname="Barnes" fullname="M. Barnes"></author>
<author initials="T." surname="Li" fullname="T. Li"></author>
<author initials="R." surname="Atkinson" fullname="R. Atkinson"></author>
<date year="2009" month="October" />
</front>
<seriesInfo name="RFC" value="5709" />
</reference>
<?rfc include="reference.RFC.6039.xml"?>
<?rfc include="reference.RFC.6151.xml"?>
<?rfc include="reference.RFC.6194.xml"?>
<reference anchor="OSPF3-AUTH">
<front>
<title>Supporting Authentication Trailer for OSPFv3</title>
<author initials="M." surname="Bhatia" fullname="M. Bhatia"></author>
<author initials="V." surname="Manral" fullname="V. Manral"></author>
<author initials="A." surname="Lindem" fullname="A. Lindem"></author>
<date year="2012" month="February" />
</front>
<seriesInfo name="RFC" value="6506" />
</reference>
<?rfc include="reference.RFC.6709.xml"?>
<?rfc include="reference.RFC.6982.xml"?>
<?rfc include="reference.I-D.chroboczek-babel-extension-mechanism"?>
<reference anchor="OSPF3-AUTH-BIS">
<front>
<title>Supporting Authentication Trailer for OSPFv3</title>
<author initials="M." surname="Bhatia" fullname="M. Bhatia"></author>
<author initials="V." surname="Manral" fullname="V. Manral"></author>
<author initials="A." surname="Lindem" fullname="A. Lindem"></author>
<date year="2014" month="March" />
</front>
<seriesInfo name="RFC" value="7166" />
</reference>
<?rfc include="reference.RFC.7183.xml"?>
<?rfc include="reference.RFC.7186.xml"?>
</references>
<section title="Figures and Tables">
<figure anchor="dataflows" title="Interaction Diagram">
<artwork align="center"><![CDATA[
+-------------------------------------------------------------+
| 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: ===>
]]></artwork>
</figure>
<figure anchor="datagram_structure" title="Babel Datagram Structure">
<artwork align="center"><![CDATA[
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 | |
| | | | | | | | | | | | |
+--+-----+------+-----+------+...+-----+------+...+------+-----+--+
]]></artwork>
</figure>
<texttable anchor="tlv_namespace" title="Babel TLV Types 0 through 12">
<ttcol align="right">Value</ttcol>
<ttcol>Name</ttcol>
<ttcol>Reference</ttcol>
<c>0</c>
<c>Pad1</c>
<c><xref target="BABEL" /></c>
<c>1</c>
<c>PadN</c>
<c><xref target="BABEL" /></c>
<c>2</c>
<c>Acknowledgement Request</c>
<c><xref target="BABEL" /></c>
<c>3</c>
<c>Acknowledgement</c>
<c><xref target="BABEL" /></c>
<c>4</c>
<c>Hello</c>
<c><xref target="BABEL" /></c>
<c>5</c>
<c>IHU</c>
<c><xref target="BABEL" /></c>
<c>6</c>
<c>Router-Id</c>
<c><xref target="BABEL" /></c>
<c>7</c>
<c>Next Hop</c>
<c><xref target="BABEL" /></c>
<c>8</c>
<c>Update</c>
<c><xref target="BABEL" /></c>
<c>9</c>
<c>Route Request</c>
<c><xref target="BABEL" /></c>
<c>10</c>
<c>Seqno Request</c>
<c><xref target="BABEL" /></c>
<c>11</c>
<c>TS/PC</c>
<c>this document</c>
<c>12</c>
<c>HMAC</c>
<c>this document</c>
</texttable>
<texttable anchor="sample_noauth" title="A Babel Packet without Authentication TLVs">
<ttcol>Packet field</ttcol>
<ttcol>Packet octets (hexadecimal)</ttcol>
<ttcol>Meaning (decimal)</ttcol>
<c>Magic</c>
<c>2a</c>
<c>42</c>
<c>Version</c>
<c>02</c>
<c>version 2</c>
<c>Body length</c>
<c>00:14</c>
<c>20 octets</c>
<c>[TLV] Type</c>
<c>04</c>
<c>4 (Hello)</c>
<c>[TLV] Length</c>
<c>06</c>
<c>6 octets</c>
<c>Reserved</c>
<c>00:00</c>
<c>no meaning</c>
<c>Seqno</c>
<c>09:25</c>
<c>2341</c>
<c>Interval</c>
<c>01:90</c>
<c>400 (4.00 s)</c>
<c>[TLV] Type</c>
<c>08</c>
<c>8 (Update)</c>
<c>[TLV] Length</c>
<c>0a</c>
<c>10 octets</c>
<c>AE</c>
<c>00</c>
<c>0 (wildcard)</c>
<c>Flags</c>
<c>40</c>
<c>default router-id</c>
<c>Plen</c>
<c>00</c>
<c>0 bits</c>
<c>Omitted</c>
<c>00</c>
<c>0 bits</c>
<c>Interval</c>
<c>ff:ff</c>
<c>infinity</c>
<c>Seqno</c>
<c>68:21</c>
<c>26657</c>
<c>Metric</c>
<c>ff:ff</c>
<c>infinity</c>
</texttable>
<texttable anchor="sample_padded" title="A Babel Packet with Each HMAC TLV
Padded Using IPv6 Address
fe80&wj;:&wj;:&wj;0a11&wj;:&wj;96ff&wj;:&wj;fe1c&wj;:&wj;10c8">
<ttcol>Packet field</ttcol>
<ttcol>Packet octets (hexadecimal)</ttcol>
<ttcol>Meaning (decimal)</ttcol>
<c>Magic</c>
<c>2a</c>
<c>42</c>
<c>Version</c>
<c>02</c>
<c>version 2</c>
<c>Body length</c>
<c>00:4c</c>
<c>76 octets</c>
<c>[TLV] Type</c>
<c>04</c>
<c>4 (Hello)</c>
<c>[TLV] Length</c>
<c>06</c>
<c>6 octets</c>
<c>Reserved</c>
<c>00:00</c>
<c>no meaning</c>
<c>Seqno</c>
<c>09:25</c>
<c>2341</c>
<c>Interval</c>
<c>01:90</c>
<c>400 (4.00 s)</c>
<c>[TLV] Type</c>
<c>08</c>
<c>8 (Update)</c>
<c>[TLV] Length</c>
<c>0a</c>
<c>10 octets</c>
<c>AE</c>
<c>00</c>
<c>0 (wildcard)</c>
<c>Flags</c>
<c>40</c>
<c>default router-id</c>
<c>Plen</c>
<c>00</c>
<c>0 bits</c>
<c>Omitted</c>
<c>00</c>
<c>0 bits</c>
<c>Interval</c>
<c>ff:ff</c>
<c>infinity</c>
<c>Seqno</c>
<c>68:21</c>
<c>26657</c>
<c>Metric</c>
<c>ff:ff</c>
<c>infinity</c>
<c>[TLV] Type</c>
<c>0b</c>
<c>11 (TS/PC)</c>
<c>[TLV] Length</c>
<c>06</c>
<c>6 octets</c>
<c>PacketCounter</c>
<c>00:01</c>
<c>1</c>
<c>Timestamp</c>
<c>52:1d:7e:8b</c>
<c>1377664651</c>
<c>[TLV] Type</c>
<c>0c</c>
<c>12 (HMAC)</c>
<c>[TLV] Length</c>
<c>16</c>
<c>22 octets</c>
<c>KeyID</c>
<c>00:c8</c>
<c>200</c>
<c>Digest</c>
<c>fe:80:00:00:00:00:00:00:0a:11</c>
<c>padding</c>
<c></c>
<c>96:ff:fe:1c:10:c8:00:00:00:00</c>
<c></c>
<c>[TLV] Type</c>
<c>0c</c>
<c>12 (HMAC)</c>
<c>[TLV] Length</c>
<c>16</c>
<c>22 octets</c>
<c>KeyID</c>
<c>00:64</c>
<c>100</c>
<c>Digest</c>
<c>fe:80:00:00:00:00:00:00:0a:11</c>
<c>padding</c>
<c></c>
<c>96:ff:fe:1c:10:c8:00:00:00:00</c>
<c></c>
</texttable>
<texttable anchor="sample_results" title="A Babel Packet with Each HMAC TLV
Containing an HMAC Result">
<ttcol>Packet field</ttcol>
<ttcol>Packet octets (hexadecimal)</ttcol>
<ttcol>Meaning (decimal)</ttcol>
<c>Magic</c>
<c>2a</c>
<c>42</c>
<c>Version</c>
<c>02</c>
<c>version 2</c>
<c>Body length</c>
<c>00:4c</c>
<c>76 octets</c>
<c>[TLV] Type</c>
<c>04</c>
<c>4 (Hello)</c>
<c>[TLV] Length</c>
<c>06</c>
<c>6 octets</c>
<c>Reserved</c>
<c>00:00</c>
<c>no meaning</c>
<c>Seqno</c>
<c>09:25</c>
<c>2341</c>
<c>Interval</c>
<c>01:90</c>
<c>400 (4.00 s)</c>
<c>[TLV] Type</c>
<c>08</c>
<c>8 (Update)</c>
<c>[TLV] Length</c>
<c>0a</c>
<c>10 octets</c>
<c>AE</c>
<c>00</c>
<c>0 (wildcard)</c>
<c>Flags</c>
<c>40</c>
<c>default router-id</c>
<c>Plen</c>
<c>00</c>
<c>0 bits</c>
<c>Omitted</c>
<c>00</c>
<c>0 bits</c>
<c>Interval</c>
<c>ff:ff</c>
<c>infinity</c>
<c>Seqno</c>
<c>68:21</c>
<c>26657</c>
<c>Metric</c>
<c>ff:ff</c>
<c>infinity</c>
<c>[TLV] Type</c>
<c>0b</c>
<c>11 (TS/PC)</c>
<c>[TLV] Length</c>
<c>06</c>
<c>6 octets</c>
<c>PacketCounter</c>
<c>00:01</c>
<c>1</c>
<c>Timestamp</c>
<c>52:1d:7e:8b</c>
<c>1377664651</c>
<c>[TLV] Type</c>
<c>0c</c>
<c>12 (HMAC)</c>
<c>[TLV] Length</c>
<c>16</c>
<c>22 octets</c>
<c>KeyID</c>
<c>00:c8</c>
<c>200</c>
<c>Digest</c>
<c>c6:f1:06:13:30:3c:fa:f3:eb:5d</c>
<c>HMAC result</c>
<c></c>
<c>60:3a:ed:fd:06:55:83:f7:ee:79</c>
<c></c>
<c>[TLV] Type</c>
<c>0c</c>
<c>12 (HMAC)</c>
<c>[TLV] Length</c>
<c>16</c>
<c>22 octets</c>
<c>KeyID</c>
<c>00:64</c>
<c>100</c>
<c>Digest</c>
<c>df:32:16:5e:d8:63:16:e5:a6:4d</c>
<c>HMAC result</c>
<c></c>
<c>c7:73:e0:b5:22:82:ce:fe:e2:3c</c>
<c></c>
</texttable>
</section>
<section title="Test Vectors">
<t>The test vectors below may be used to verify the correctness of some
procedures performed by an implementation of this mechanism, namely:
<list style="symbols">
<t>appending of TS/PC and HMAC TLVs to the Babel packet body,</t>
<t>padding of the HMAC TLV(s),</t>
<t>computation of the HMAC result(s), and</t>
<t>placement of the result(s) in the TLV(s).</t>
</list>
This verification isn't exhaustive, there are other important implementation aspects
that would require testing methods of their own.</t>
<t>The test vectors were produced as follows.
<list style="numbers">
<t>A Babel speaker with a network interface with IPv6 link-local address
fe80&wj;:&wj;:&wj;0a11&wj;:&wj;96ff&wj;:&wj;fe1c&wj;:&wj;10c8 was
configured to use two CSAs for the interface:
<list style="symbols">
<t>CSA1={HashAlgo=RIPEMD-160, KeyChain={{LocalKeyID=200, AuthKeyOctets=Key26}}}</t>
<t>CSA2={HashAlgo=SHA-1, KeyChain={{LocalKeyId=100, AuthKeyOctets=Key70}}}</t>
</list>
The authentication keys above are:
<list style="symbols">
<t>Key26 in ASCII:
<figure>
<artwork align="left">
ABCDEFGHIJKLMNOPQRSTUVWXYZ
</artwork>
</figure></t>
<t>Key26 in hexadecimal:
<figure>
<artwork align="left">
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
</artwork>
</figure>
</t>
<t>Key70 in ASCII:
<figure>
<artwork align="left">
This=key=is=exactly=70=octets=long.=ABCDEFGHIJKLMNOPQRSTUVWXYZ01234567
</artwork>
</figure></t>
<t>Key70 in hexadecimal:
<figure>
<artwork align="left">
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
</artwork>
</figure>
</t>
</list>
The length of each key was picked to relate (in the terms of
<xref target="hmac" />) with the properties of respective hash algorithm as
follows:
<list style="symbols">
<t>the digest length (L) of both RIPEMD-160 and SHA-1 is 20 octets,</t>
<t>the internal block size (B) of both RIPEMD-160 and SHA-1 is 64 octets,</t>
<t>the length of Key26 (26) is greater than L but less than B, and</t>
<t>the length of Key70 (70) is greater than B (and thus greater than L).</t>
</list>
KeyStartAccept, KeyStopAccept, KeyStartGenerate and KeyStopGenerate were set
to make both authentication keys valid.</t>
<t>The instance of the original protocol of the speaker produced a Babel
packet (PktO) to be sent from the interface. <xref target="sample_noauth" />
provides a decoding of PktO, contents of which is below:
<figure>
<artwork align="left">
2a:02:00:14:04:06:00:00:09:25:01:90:08:0a:00:40
00:00:ff:ff:68:21:ff:ff
</artwork>
</figure>
</t>
<t>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 necessary amount of zeroes. <xref target="sample_padded" />
provides a decoding of the resulting temporary packet (PktT), contents of
which is below:
<figure>
<artwork align="left">
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
</artwork>
</figure>
</t>
<t>The authentication mechanism produced two HMAC results, performing the
computations as follows:
<list style="symbols">
<t>For H=RIPEMD-160, K=Key26, and Text=PktT the HMAC result is:
<figure>
<artwork align="left">
c6:f1:06:13:30:3c:fa:f3:eb:5d:60:3a:ed:fd:06:55
83:f7:ee:79
</artwork>
</figure>
</t>
<t>For H=SHA-1, K=Key70, and Text=PktT the HMAC result is:
<figure>
<artwork align="left">
df:32:16:5e:d8:63:16:e5:a6:4d:c7:73:e0:b5:22:82
ce:fe:e2:3c
</artwork>
</figure>
</t>
</list>
</t>
<t>The authentication mechanism placed each HMAC result into respective
HMAC TLV, producing the final authenticated Babel packet (PktA), which was
eventually sent from the interface. <xref target="sample_results" /> provides
a decoding of PktA, contents of which is below:
<figure>
<artwork align="left">
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
</artwork>
</figure>
</t>
</list></t>
<t>Interpretation of this process is to be done in the view of
<xref target="dataflows" />, differently for the sending and the receiving
directions.</t>
<t>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 <xref target="tx_procedure" />)
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 respective results above and
the final authenticated packet MUST exactly match the PktA above.</t>
<t>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 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 the verification
purpose, it MUST exactly match the second result above.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:40:12 |