| Network Working Group | D. Ovsienko |
| Internet-Draft | March 5, 2018 |
| Obsoletes: 7298 (if approved) | |
| Intended status: Standards Track | |
| Expires: September 6, 2018 |
Babel HMAC Cryptographic Authentication
draft-ovsienko-babel-rfc7298bis-00
This document describes a cryptographic authentication mechanism for the Babel routing protocol. The mechanism uses two TLV types and one sub-STV type for the authentication data, uses HMAC and is both optional and backward compatible. This document obsoletes RFC 7298.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2018.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
[RFC Editor: before publication please remove the sentence below.] 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 the operation of a basic Babel routing protocol instance ("instance of the original protocol"). This document ("this specification") defines data structures, encoding, and the operation of an extension to the Babel protocol, an authentication mechanism ("this mechanism"). Both the instance of the original protocol and this mechanism are mostly self-contained and interact only at coupling points defined in this specification.
A major design goal of this mechanism is transparency to operators that is not affected by implementation and configuration specifics. A complying implementation makes all meaningful details of authentication-specific processing clear to the operator, even when some of the operational parameters cannot be changed.
The currently established (see [RIP2-AUTH], [OSPF2-AUTH], [OSPF3-AUTH], [ISIS-AUTH-A], 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:
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.
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.
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.
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 ([RFC3931] Section 5.4.1) and MANET protocols allow for several ([RFC7183] Section 6.1) results per authenticated packet.
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).
These limits establish a basic competition between the configured keys and (in the receiving case) an additional competition between the supplied HMAC results. This specification defines related data structures and procedures in a way to make such competition transparent and predictable for an operator.
Wherever this specification mentions the operator reading or changing a particular data structure, variable, parameter, or event counter "at runtime", it is up to the implementor how this is to be done. For example, the implementation can employ an interactive CLI, or a management protocol such as SNMP, or an inter-process communication mean such as a local socket, or a combination of these.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
[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.
Section 4.5 of [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. This design choice fully conforms to BCP 201.
An implementation of this mechanism MUST include support for two hash algorithms:
Besides that, an implementation of this mechanism MAY include support for additional hash algorithms, provided each such algorithm is publicly and openly specified and its digest length is 128 bits or more (to meet the constraint implied in Section 2.2). Implementors SHOULD consider strong, well-known hash algorithms as additional implementation options and MUST NOT consider hash algorithms for that by the time of implementation meaningful attacks exist or that are commonly viewed as deprecated.
In the latter case it is important to take into account considerations both common (such as those made in [RFC4270]) and specific to the HMAC application of the hash algorithm. E.g., [RFC6151] considers MD5 collisions and concludes that new protocol designs should not use HMAC-MD5, while [RFC6194] includes a comparable analysis of SHA-1 that finds HMAC-SHA-1 secure for the same purpose.
For example, the following hash algorithms meet these requirements at the time of this writing (in alphabetical order):
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.
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:
Description of the padding procedure:
For an example of a Babel packet with padded HMAC TLVs see Table 3.
Operation of this mechanism may involve multiple local and multiple remote cryptographic sequence numbers, each essentially being a 48‑bit unsigned integer. This specification uses a term "TS/PC number" to avoid confusion with the route's (Section 2.5 of [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‑bit number, each handled in its specific way (see Section 5.1):
0 1 2 3 4
0 1 2 3 4 5 6 7 8 9 0 // 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS // | PC |
+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//
The high-order 32 bits are called "timestamp" (TS) and the low-order 16 bits are called "packet counter" (PC).
This mechanism stores, updates, compares, and encodes each TS/PC number as two independent unsigned integers, TS and PC respectively. Such comparison of TS/PC numbers performed in item 3 of Section 5.4 is algebraically equivalent to comparison of respective 48‑bit unsigned integers. Any byte order conversion, when required, is performed on TS and PC parts independently.
The algorithm description below uses the following nomenclature, which is consistent with [FIPS-198]:
The algorithm below is the original, unmodified HMAC construct as defined in both [RFC2104] and [FIPS-198], hence it is different from the algorithms defined in [RIP2-AUTH], [ISIS-AUTH-B], [OSPF2-AUTH], and [OSPF3-AUTH] in exactly two regards:
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.
Description of the algorithm:
A First-Hash, also known as the inner hash, is computed as follows:
First-Hash = H(Ko XOR Ipad || Text)
A second hash, also known as the outer hash, is computed as follows:
Second-Hash = H(Ko XOR Opad || First-Hash)
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 [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).
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 Section 7.3). Current value of RxAuthRequired directly affects the receiving procedure defined in Section 5.4. 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.
LocalTS is a 32-bit unsigned integer variable, it is the TS part of a per-interface TS/PC number. LocalTS is a strictly per-interface variable not intended to be changed by the operator. Its initialization is explained in Section 5.1.
LocalPC is a 16-bit unsigned integer variable, it is the PC part of a per-interface TS/PC number. LocalPC is a strictly per-interface variable not intended to be changed by the operator. Its initialization is explained in Section 5.1.
MaxDigestsIn is an unsigned integer parameter conceptually purposed for limiting the amount of CPU time spent processing a received authenticated packet. The receiving procedure performs the most CPU-intensive operation, the HMAC computation, only at most MaxDigestsIn (Section 5.4 item 8) times for a given packet.
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.
MaxDigestsOut is an unsigned integer parameter conceptually purposed for limiting the amount of a sent authenticated packet's space spent on authentication data. The sending procedure adds at most MaxDigestsOut (Section 5.3 item 7) HMAC results to a given packet, concurring with the output buffer management explained in Section 6.2.
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 Section 6.2). An implementation MUST allow the operator to discover the effective value of MaxDigestsOut at runtime or from the system documentation.
The ANM (Authentic Neighbours Memory) table resembles the neighbour table defined in Section 3.2.4 of [BABEL]. Note that the term "neighbour table" means the neighbour table of the original Babel specification, and the term "ANM table" means the table defined herein. Indexing of the ANM table is done in exactly the same way as indexing of the neighbour table, but purpose, field set and associated procedures are different.
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 [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 ANMTimeout parameter defined in Section 3.7) a copy of TS/PC number advertised in authentic packets by each remote Babel speaker.
The ANM table is indexed by pairs of the form (Interface, Source). Every table entry consists of the following fields: Section 5.4 item 10). If the timer expires, the entry is deleted from the ANM table.
Each ANM table entry has an associated aging timer, which is reset by the receiving procedure (
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.
ANMTimeout is an unsigned integer parameter. An implementation SHOULD make ANMTimeout a per-interface parameter, but MAY make it specific to the whole protocol instance. ANMTimeout 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 ANMTimeout set, but it may not provide the best overall result for specific network segments and implementations of this mechanism.
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 Section 5.1). 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.
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.
Assuming that in such cases the operators would prefer to use a lower ANMTimeout 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 ANMTimeout to a value between 30 and 300 seconds.
At the same time, network segments may exist with every Babel speaker having its advertised TS/PC number strictly increasing over the deployed lifetime. Assuming that in such cases the operators would prefer using a much higher ANMTimeout value, an implementation SHOULD allow the operator to change the value of ANMTimeout at runtime or by means of Babel speaker restart. An implementation MUST allow the operator to discover the effective value of ANMTimeout at runtime or from the system documentation.
The purpose of the sent TS/PC numbers table is to provide protection from those attacks that introduce a meaningful arbitrary delay into the protocol exchange. Such attacks are in scope because the original specification does not relate a specific received IHU TLV to a specific sent Hello TLV. This way, if an adversary intercepts all packets sent by a Babel speaker and starts replaying them later, the IHU TLVs will mislead respective speakers into detecting bidirectional reachability with the neighbour and processing the other TLVs from the replayed packets. Since the checks based on the ANM table are unable to tell the replayed packets when the replayed TS/PC number is strictly increasing, this mechanism adds a proof of freshness to the protocol exchange to address this problem.
The sent TS/PC numbers table is indexed by pairs of the form (Interface, FirstTimestamp). Every table entry consists of the following fields: Section 3.9) seconds into the past. Consequently, the time reference MUST NOT be affected by the speaker's clock adjustments (monotonic clock and system uptime are examples of good time references in this sense).
An implementation MUST at least once per second remove from the table all entries that have FirstTimestamp more than TSPCMaxRTT (see
An implementation SHOULD NOT retain the contents of this table across restarts of the Babel speaker. An implementation SHOULD allow the operator to retrieve the current contents of the table at runtime.
TSPCMaxRTT is an unsigned integer parameter. An implementation SHOULD make TSPCMaxRTT a per-interface parameter, but MAY make it specific to the whole protocol instance. TSPCMaxRTT limits the maximum age (in seconds) of entries in the sent TS/PC numbers table. On one hand, TSPCMaxRTT should be set as low as possible to leave out the speakers that try to respond to obviously stale Hello TLVs. On the other, a normal Babel protocol exchange requires some minimal leeway to accommodate its timers, jitter, and natural delays and losses in transmission, so good judgement should be applied.
An implementation SHOULD set the default value of TSPCMaxRTT to a value between 30 and 300 seconds, SHOULD allow the operator to change the value of TSPCMaxRTT at runtime or by means of a Babel speaker restart, and MUST allow the operator to discover the effective value of TSPCMaxRTT at runtime or from the system documentation.
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 (Section 5.3 item 1) and the receiving (Section 5.4 item 1) procedures address this convention accordingly.
A single CSA structure consists of the following fields:
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 Section 5.2 will be deterministically ordered as well.
An implementation SHOULD allow an operator to set any arbitrary order of elements within a given interface's sequence of CSAs and within the KeyChain sequence of a given CSA. Regardless 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.
Note that none of the CSA structure fields is constrained to contain unique values. Section 6.4 explains this in more detail. It is possible for the KeyChain sequence to be empty, although this is not the intended manner of CSAs use.
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.
An Effective Security Association (ESA) is a data structure immediately used in sending (Section 5.3) and receiving (Section 5.4) procedures. Its conceptual purpose is to determine a runtime interface between those procedures and the deriving procedure defined in Section 5.2. All ESAs are temporary data units managed as elements of finite sequences that are not intended for a persistent storage. Element ordering within each such finite sequence ("sequence of ESAs" hereafter) MUST be preserved as long as the sequence exists.
A single ESA structure consists of the following fields:
Note that among the protocol data structures introduced by this mechanism ESA is the only one not directly interfaced with the system operator (see Figure 1), 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 (Section 5.2), the sending (Section 5.3), and the receiving (Section 5.4) procedures are defined in terms of the ESA structure and its semantics provided herein. ESA is as meaningful for a correct implementation as the other protocol data structures.
Choice of encoding is very important in the long term. The protocol encoding limits various authentication mechanism designs and encodings, which in turn limit future developments of the protocol.
Considering existing implementations of 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, Section 4.3 and Appendix C of [BABEL]:
Considering each principal extension mean for the specific purpose of adding authentication data items to each protocol packet, the following arguments can be made:
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 Table 1).
The purpose of a TS/PC TLV is to store a single TS/PC number. There is exactly one TS/PC TLV in an authenticated Babel packet.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 11 | Length | PacketCounter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Section 2.3).
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‑bit equivalent (see
Considering the "expected length" and the "extra data" in the definition of Section 4.3 of [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 (Section 5.4 items 3 and 10). The sending procedure produces a TS/PC TLV with body length equal to the expected and Length field set respectively (Section 5.3 item 5).
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 Section 6.2.
The purpose of an HMAC TLV is to store a single HMAC result. To assist a receiver in reproducing the HMAC computation, LocalKeyID modulo 2^16 of the authentication key is also provided in the TLV. There is at least one HMAC TLV in an authenticated Babel packet.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 12 | Length | KeyID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Digest... +-+-+-+-+-+-+-+-+-+-+-+-
Fields:
Considering the "expected length" and the "extra data" in the definition of Section 4.3 of [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 (Section 5.4 item 8 and Section 2.2 respectively). The sending procedure produces HMAC TLVs with Length field precisely sizing the Digest field to match digest length of the hash algorithm used (Section 5.3 items 7 and 10).
The HMAC TLV structure defined herein is final, future Babel extensions MUST NOT extend it with any extra data.
The purpose of a TS/PC sub-TLV is to store a single TS/PC number. There is at most one TS/PC sub-TLV in an IHU TLV.
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 = TBD1 | Length | PacketCounter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
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‑bit equivalent (see Section 2.3) MUST be strictly increasing within the scope of a given interface of a Babel speaker as long as the protocol instance is continuously operating. This property combined with ANM tables of neighbouring Babel speakers provides them with the most basic replay attack protection.
Initialization and increment are two principal updates performed on an interface TS/PC number. The initialization is performed when a new interface becomes a part of a Babel protocol instance. The increment is performed by the sending procedure (Section 5.3 item 2) before advertising the TS/PC number in a TS/PC TLV.
Depending on 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.
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
Section 3.6 and Section 3.7).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.
In this case the advertised TS/PC number would also remain unique across the speaker's deployed lifetime, relying on NVRAM for storing multiple TS numbers, one per interface.
As long as the TS/PC number retains its mandatory property stated above, it is up to the implementor, 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 Section 3.7) management of ANMTimeout in a network segment.
Note that wrapping (0xFFFFFFFF + 1 = 0x00000000) of LastTS is unlikely, but possible, causing the advertised TS/PC number to be reused. Resolving this situation requires replacing all authentication keys of the involved interface. In addition to that, if the wrap was caused by a timestamp reaching its end of epoch, using this mechanism will be impossible for the involved interface until some different timestamp or update implementation method is used.
Neither receiving nor sending procedures work with the contents of interface's sequence of CSAs directly, both (Section 5.4 item 5 and Section 5.3 item 6 respectively) derive a sequence of ESAs from the sequence of CSAs and use the derived sequence (see Figure 1). There are two main goals achieved through this indirection: Section 6.3.
The deriving procedure uses the following input arguments:
The processing of input arguments begins with an empty output sequence of ESAs and consists of the following steps:
Note well that there are no special exceptions. Remove all expired keys, even if there are no keys left after that (see
Section 7.4).Append this ESA to the end of the output sequence.
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".
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
Perform the following authentication-specific processing after the instance of the original protocol considers an outgoing Babel packet ready for sending, but before the packet is actually sent (see Figure 1). After that send the packet regardless if the authentication-specific processing modified the outgoing packet or left it intact.
Update the Length field of the IHU TLV as necessary.
Note that the current step may involve byte order conversion.
As soon as there are MaxDigestsOut HMAC TLVs added to the current packet body, immediately proceed to the next step.
Note that even when the derived sequence of ESAs is empty, the packet is sent anyway with only a TS/PC TLV appended to its body. Although such a packet would not be authenticated, the presence of the sole TS/PC TLV would indicate authentication key exhaustion to operators of neighbouring Babel speakers. See also Section 7.4.
Also note that it is possible to place the authentication-specific TLVs in the packet's sequence of TLVs in a number of different valid ways so long as there is exactly one TS/PC TLV in the sequence and the ordering of HMAC TLVs relative to each other, as produced in step 5 above, is preserved.
For example, see Figure 2. The diagrams represent a Babel packet without (D1) and with (D2, D3, D4) authentication-specific TLVs. The optional trailing data block that is present in D1 is preserved in D2, D3, and D4. Indexing (1, 2, ..., n) of the HMAC TLVs means the order in which the sending procedure produced them (and respectively the HMAC results). In D2 the added TLVs are appended: the previously existing TLVs are followed by the TS/PC TLV, which is followed by the HMAC TLVs. In D3 the added TLVs are prepended: the TS/PC TLV is the first and is followed by the HMAC TLVs, which are followed by the previously existing TLVs. In D4 the added TLVs are intermixed with the previously existing TLVs and the TS/PC TLV is placed after the HMAC TLVs. All three packets meet the requirements above.
Implementors SHOULD use appending (D2) for adding the authentication-specific TLVs to the sequence, this is expected to result in more straightforward implementation and troubleshooting in most use cases.
Perform the following authentication-specific processing after an incoming Babel packet is received from the local network stack, but before it is acted upon by the Babel protocol instance (see Figure 1). 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). [BABEL] and is not the receiving speaker's own address (see item (e) of Section 9).
Note that the current step may involve byte order conversion.
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
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 (Section 7.3) implementation.
A Babel speaker implementing this mechanism SHOULD maintain a set of counters for the following events, per protocol instance and per interface:
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.
Section 3.1 of [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 (Section 5.3 item 7) exact knowledge of packet source address for proper padding of HMAC TLVs.
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 Figure 1). 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.
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 [BABEL]).
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 Figure 2) 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:
R = St + MaxDigestsOut * Sh = = 8 + MaxDigestsOut * (4 + Lmax)
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.
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 [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.
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.
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.
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 (Section 5.2 item 4).
One of the intentions of this is to define the security association management in a way that allows the addressing of some specifics of Babel as a mesh routing protocol. For example, a system operator configuring a Babel speaker to participate in more than one administrative domain could find each domain using its own authentication key (AuthKeyOctets) under the same LocalKeyID value, e.g., a "well-known" or "default" value like 0 or 1. Since reconfiguring the domains to use distinct LocalKeyID values isn't always feasible, the multi-domain Babel speaker using several distinct authentication keys under the same LocalKeyID would make a valid use case for such duplication.
Furthermore, if 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 Section 9). This would make a similar use case.
Another intention of this design decision is to decouple security association management from authentication key management as much as possible, so that the latter, be it manual keying or a key management protocol, could be designed and implemented independently (as respective reasoning made in Section 3.1 of [RIP2-AUTH] still applies). This way the additional key management constraints, if any, would remain out of scope of this authentication mechanism. A similar thinking justifies LocalKeyID field having bit length in ESA structure definition, but not in that of CSA.
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.
The Babel design requires a bidirectional 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 [BABEL]).
The receiving procedure treats a packet as authentic as soon as one of its HMAC TLVs passes the check against the derived sequence of ESAs. This allows for packet exchange authenticated with multiple (hash algorithm, authentication key) pairs simultaneously, in combinations as arbitrary as permitted by MaxDigestsIn and MaxDigestsOut.
For example, consider three Babel speakers with one interface each, configured with the following CSAs:
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.
Consider a similar set of speakers configured with different CSAs:
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.
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 Section 3.4 and Section 3.5), 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.
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 Section 9.
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 Section 3.1. This measure is similar to the "transition mode" suggested in Section 5 of [OSPF3-AUTH].
An operator performing the migration needs to arrange configuration changes as follows:
Likewise, temporarily setting RxAuthRequired to FALSE can be used to migrate smoothly from an authenticated packet exchange back to unauthenticated one.
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: [RIP2-AUTH]).
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
Although the deriving procedure does not allow for any exceptions in expired keys filtering (Section 5.2 item 2), the operator can trivially enforce one of the two remaining behaviour options through local key management procedures. In particular, when using the key over its intended lifetime is 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.
[RFC Editor: before publication please remove this section and the reference to [RFC7942], along the guidelines of which this section exists to assist document reviewers.]
FIXME: update with the current status
Use of this mechanism implies requirements common to a use of shared authentication keys, including, but not limited to: BCP 107, BCP 132, and [RFC6039] may be suggested as starting points).
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 (
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 Section 7.4. With that and the guidance of Section 5.1 of [RIP2-AUTH] in mind, in such an event the Babel speaker MUST send a "last key expired" notification to the operator (e.g. via syslog, SNMP, and/or other implementation-specific means), most likely in relation to the item (b) of Section 5.5. Also, any actual occurrence of an authentication key expiration MUST cause a security event to be logged by the implementation. The log item MUST include at least a note that the authentication key has expired, the Babel routing protocol instance(s) affected, the network interface(s) affected, the LocalKeyID that is affected, and the current date/time. Operators are encouraged to check such logs as an operational security practice.
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:
The following in-scope concern is only partially addressed:
The following in-scope concerns are not addressed:
[RFC Editor: please do not remove this section.]
Because this document obsoletes [RFC7298], IANA is asked to update the existing "Babel TLV Types" protocol registry defined in Section 5 of [RFC7557] such that the TLV types 11 and 12 refer to this document instead of [RFC7298]. Also IANA is asked to assign a sub-TLV type of TBD1 to the "TS/PC" sub-TLV from the the existing "Babel Sub-TLV Types" registry defined in Section 5 of [RFC7557].
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC4291] | Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006. |
| [RFC7696] | Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015. |
| [RFC8174] | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. |
| [BABEL] | Chroboczek, J. and D. Schinazi, "The Babel Routing Protocol", Internet-Draft draft-ietf-babel-rfc6126bis-04, October 2017. |
+-------------------------------------------------------------+ | authentication-specific statistics | +-------------------------------------------------------------+ ^ | ^ | v | | +-----------------------------------------------+ | | | system operator | | | +-----------------------------------------------+ | | ^ | ^ | ^ | ^ | ^ | | | | v | | | | | | | v | +---+ +---------+ | | | | | | +---------+ +---+ | |->| ANM | | | | | | | | LocalTS |->| | | R |<-| table | | | | | | | | LocalPC |<-| T | | x | +---------+ | v | v | v +---------+ | x | | | +----------------+ +---------+ +----------------+ | | | p | | MaxDigestsIn | | | | MaxDigestsOut | | p | | r |<-| ANMTimeout | | CSAs | | |->| r | | o | | RxAuthRequired | | | | | | o | | c | +----------------+ +---------+ +----------------+ | c | | e | +-------------+ | | +-------------+ | e | | s | | Rx ESAs | | | | Tx ESAs | | s | | s |<-| (temporary) |<----+ +---->| (temporary) |->| s | | i | +-------------+ +-------------+ | i | | n | +------------------------------+----------------+ | n | | g | | instance of | output buffers |=>| g | | |=>| the original +----------------+ | | | | | protocol | source address |->| | +---+ +------------------------------+----------------+ +---+ /\ | || || v \/ +-------------------------------------------------------------+ | network stack | +-------------------------------------------------------------+ /\ || /\ || /\ || /\ || || \/ || \/ || \/ || \/ +---------+ +---------+ +---------+ +---------+ | speaker | | speaker | ... | speaker | | speaker | +---------+ +---------+ +---------+ +---------+ Flow of control data : ---> Flow of Babel datagrams/packets: ===>
Figure 1: Interaction Diagram
P
|<---------------------------->| (D1)
| B |
| |<------------------------->|
| | |
+--+-----+-----+...+-----+-----+--+ P: Babel packet
|H |some |some | |some |some |T | H: Babel packet header
| |TLV |TLV | |TLV |TLV | | B: Babel packet body
| | | | | | | | T: optional trailing data block
+--+-----+-----+...+-----+-----+--+
P
|<----------------------------------------------------->| (D2)
| B |
| |<-------------------------------------------------->|
| | |
+--+-----+-----+...+-----+-----+------+------+...+------+--+
|H |some |some | |some |some |TS/PC |HMAC | |HMAC |T |
| |TLV |TLV | |TLV |TLV |TLV |TLV 1 | |TLV n | |
| | | | | | | | | | | |
+--+-----+-----+...+-----+-----+------+------+...+------+--+
P
|<----------------------------------------------------->| (D3)
| B |
| |<-------------------------------------------------->|
| | |
+--+------+------+...+------+-----+-----+...+-----+-----+--+
|H |TS/PC |HMAC | |HMAC |some |some | |some |some |T |
| |TLV |TLV 1 | |TLV n |TLV |TLV | |TLV |TLV | |
| | | | | | | | | | | |
+--+------+------+...+------+-----+-----+...+-----+-----+--+
P
|<------------------------------------------------------------>| (D4)
| B |
| |<--------------------------------------------------------->|
| | |
+--+-----+------+-----+------+...+-----+------+...+------+-----+--+
|H |some |HMAC |some |HMAC | |some |HMAC | |TS/PC |some |T |
| |TLV |TLV 1 |TLV |TLV 2 | |TLV |TLV n | |TLV |TLV | |
| | | | | | | | | | | | |
+--+-----+------+-----+------+...+-----+------+...+------+-----+--+
Figure 2: Babel Datagram Structure
| Value | Name | Reference |
|---|---|---|
| 0 | Pad1 | [BABEL] |
| 1 | PadN | [BABEL] |
| 2 | Acknowledgement Request | [BABEL] |
| 3 | Acknowledgement | [BABEL] |
| 4 | Hello | [BABEL] |
| 5 | IHU | [BABEL] |
| 6 | Router-Id | [BABEL] |
| 7 | Next Hop | [BABEL] |
| 8 | Update | [BABEL] |
| 9 | Route Request | [BABEL] |
| 10 | Seqno Request | [BABEL] |
| 11 | TS/PC | this document |
| 12 | HMAC | this document |
| Packet field | Packet octets (hexadecimal) | Meaning (decimal) |
|---|---|---|
| Magic | 2a | 42 |
| Version | 02 | version 2 |
| Body length | 00:14 | 20 octets |
| [TLV] Type | 04 | 4 (Hello) |
| [TLV] Length | 06 | 6 octets |
| Reserved | 00:00 | no meaning |
| Seqno | 09:25 | 2341 |
| Interval | 01:90 | 400 (4.00 s) |
| [TLV] Type | 08 | 8 (Update) |
| [TLV] Length | 0a | 10 octets |
| AE | 00 | 0 (wildcard) |
| Flags | 40 | default router-id |
| Plen | 00 | 0 bits |
| Omitted | 00 | 0 bits |
| Interval | ff:ff | infinity |
| Seqno | 68:21 | 26657 |
| Metric | ff:ff | infinity |
| Packet field | Packet octets (hexadecimal) | Meaning (decimal) |
|---|---|---|
| Magic | 2a | 42 |
| Version | 02 | version 2 |
| Body length | 00:4c | 76 octets |
| [TLV] Type | 04 | 4 (Hello) |
| [TLV] Length | 06 | 6 octets |
| Reserved | 00:00 | no meaning |
| Seqno | 09:25 | 2341 |
| Interval | 01:90 | 400 (4.00 s) |
| [TLV] Type | 08 | 8 (Update) |
| [TLV] Length | 0a | 10 octets |
| AE | 00 | 0 (wildcard) |
| Flags | 40 | default router-id |
| Plen | 00 | 0 bits |
| Omitted | 00 | 0 bits |
| Interval | ff:ff | infinity |
| Seqno | 68:21 | 26657 |
| Metric | ff:ff | infinity |
| [TLV] Type | 0b | 11 (TS/PC) |
| [TLV] Length | 06 | 6 octets |
| PacketCounter | 00:01 | 1 |
| Timestamp | 52:1d:7e:8b | 1377664651 |
| [TLV] Type | 0c | 12 (HMAC) |
| [TLV] Length | 16 | 22 octets |
| KeyID | 00:c8 | 200 |
| Digest | fe:80:00:00:00:00:00:00:0a:11 | padding |
| 96:ff:fe:1c:10:c8:00:00:00:00 | ||
| [TLV] Type | 0c | 12 (HMAC) |
| [TLV] Length | 16 | 22 octets |
| KeyID | 00:64 | 100 |
| Digest | fe:80:00:00:00:00:00:00:0a:11 | padding |
| 96:ff:fe:1c:10:c8:00:00:00:00 |
| Packet field | Packet octets (hexadecimal) | Meaning (decimal) |
|---|---|---|
| Magic | 2a | 42 |
| Version | 02 | version 2 |
| Body length | 00:4c | 76 octets |
| [TLV] Type | 04 | 4 (Hello) |
| [TLV] Length | 06 | 6 octets |
| Reserved | 00:00 | no meaning |
| Seqno | 09:25 | 2341 |
| Interval | 01:90 | 400 (4.00 s) |
| [TLV] Type | 08 | 8 (Update) |
| [TLV] Length | 0a | 10 octets |
| AE | 00 | 0 (wildcard) |
| Flags | 40 | default router-id |
| Plen | 00 | 0 bits |
| Omitted | 00 | 0 bits |
| Interval | ff:ff | infinity |
| Seqno | 68:21 | 26657 |
| Metric | ff:ff | infinity |
| [TLV] Type | 0b | 11 (TS/PC) |
| [TLV] Length | 06 | 6 octets |
| PacketCounter | 00:01 | 1 |
| Timestamp | 52:1d:7e:8b | 1377664651 |
| [TLV] Type | 0c | 12 (HMAC) |
| [TLV] Length | 16 | 22 octets |
| KeyID | 00:c8 | 200 |
| Digest | c6:f1:06:13:30:3c:fa:f3:eb:5d | HMAC result |
| 60:3a:ed:fd:06:55:83:f7:ee:79 | ||
| [TLV] Type | 0c | 12 (HMAC) |
| [TLV] Length | 16 | 22 octets |
| KeyID | 00:64 | 100 |
| Digest | df:32:16:5e:d8:63:16:e5:a6:4d | HMAC result |
| c7:73:e0:b5:22:82:ce:fe:e2:3c |
The test vectors below may be used to verify the correctness of some procedures performed by an implementation of this mechanism, namely:
This verification isn't exhaustive, there are other important implementation aspects that would require testing methods of their own.
ABCDEFGHIJKLMNOPQRSTUVWXYZ
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
This=key=is=exactly=70=octets=long.=ABCDEFGHIJKLMNOPQRSTUVWXYZ01234567
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
2a:02:00:14:04:06:00:00:09:25:01:90:08:0a:00:40 00:00:ff:ff:68:21:ff:ff
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
c6:f1:06:13:30:3c:fa:f3:eb:5d:60:3a:ed:fd:06:55 83:f7:ee:79
df:32:16:5e:d8:63:16:e5:a6:4d:c7:73:e0:b5:22:82 ce:fe:e2:3c
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
The test vectors were produced as follows.
The authentication keys above are:
The length of each key was picked to relate (in the terms of
Section 2.4) with the properties of respective hash algorithm as follows:KeyStartAccept, KeyStopAccept, KeyStartGenerate and KeyStopGenerate were set to make both authentication keys valid.
Interpretation of this process is to be done in the view of Figure 1, differently for the sending and the receiving directions.
For the sending direction, given a Babel speaker configured using the IPv6 address and the sequence of CSAs as described above, the implementation SHOULD (see notes in Section 5.3) produce exactly the temporary packet PktT if the original protocol instance produces exactly the packet PktO to be sent from the interface. If the temporary packet exactly matches PktT, the HMAC results computed afterwards MUST exactly match respective results above and the final authenticated packet MUST exactly match the PktA above.
For the receiving direction, given a Babel speaker configured using the sequence of CSAs as described above (but a different IPv6 address), the implementation MUST (assuming 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.