Abstract
This document describes a cryptographic authentication mechanism for
Babel routing protocol, updating, but not superceding RFC 6126. The
mechanism allocates two new TLV types for the authentication data,
uses HMAC and is both optional and backward compatible.
1. Introduction
Comments are solicited and should be addressed to the author.
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.
[BABEL] ("the original specification") defines data structures,
encoding, and operation of a basic Babel routing protocol instance
("instance of the original protocol"). This document ("this
specification") defines data structures, encoding, and operation of
an extension to Babel protocol, an authentication mechanism ("this
mechanism"). Both the instance of the original protocol and this
mechanism are mostly self-contained and interact only at coupling
points defined in this specification.
A major design goal of this mechanism is such a transparency to an
operator, 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 key parameters cannot be changed.
The currently established (see [RIP2-AUTH], [OSPF2-AUTH],
[OSPF3-AUTH], and [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:
o A fixed-length unsigned integer number, typically called a
cryptographic sequence number, used in replay attack protection.
o A variable-length sequence of octets, a result of the HMAC
construct (see [RFC2104]) computed on meaningful data items of the
packet (including the cryptographic sequence number) on one hand
and a secret key on another, used in proving that both the sender
and the receiver share the same secret key and that the meaningful
data was not changed in transmission.
Depending on the design specifics either all protocol packets are
authenticated or only those protecting the integrity of protocol
exchange. This mechanism authenticates all protocol packets.
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 changing relevant parameters, the effect of
a reconfiguration.
This mechanism explicitly allows for multiple HMAC results per an
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.
An important concern addressed by this mechanism is limiting the
amount of HMAC computations done per an authenticated packet,
independently for sending and receiving. Without these limits the
number of computations per a packet could be as high as number of
configured authentication keys (in sending case) or as the number of
keys multiplied by the number of supplied HMAC results (in receiving
case).
These limits establish a basic competition between the configured
keys and (in 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.
read more.....http://tools.ietf.org/html/draft-ovsienko-babel-hmac-authentication-01