RFC 7298
Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication
7. Network Management Aspects
7.1. Backward Compatibility
Support of this mechanism is optional. It does not change the default behaviour of a Babel speaker and causes no compatibility issues with speakers properly implementing the original Babel specification. Given two Babel speakers -- one implementing this mechanism and configured for authenticated exchange (A) and another not implementing it (B) -- these speakers would not distribute routing information unidirectionally, form a routing loop, or experience other protocol logic issues specific purely to the use of this mechanism.
The Babel design requires a bidirectional neighbour reachability condition between two given speakers for a successful exchange of routing information. Apparently, neighbour reachability would be unidirectional in the case above. The presence of TS/PC and HMAC TLVs in Babel packets sent by A would be transparent to B, but a lack of authentication data in Babel packets sent by B would make them effectively invisible to the instance of the original protocol of A. Unidirectional links are not specific to the use of this mechanism; they naturally exist on their own and are properly detected and coped with by the original protocol (see Section 3.4.2 of [BABEL]).7.2. Multi-Domain Authentication
The receiving procedure treats a packet as authentic as soon as one of its HMAC TLVs passes the check against the derived sequence of ESAs. This allows for packet exchange authenticated with multiple (hash algorithm, authentication key) pairs simultaneously, in combinations as arbitrary as permitted by MaxDigestsIn and MaxDigestsOut. For example, consider three Babel speakers with one interface each, configured with the following CSAs: o speaker A: (hash algorithm H1; key SK1), (hash algorithm H1; key SK2) o speaker B: (hash algorithm H1; key SK1) o speaker C: (hash algorithm H1; key SK2) Packets sent by A would contain two HMAC TLVs each. Packets sent by B and C would contain one HMAC TLV each. A and B would authenticate the exchange between themselves, using H1 and SK1; A and C would use H1 and SK2; B and C would discard each other's packets. Consider a similar set of speakers configured with different CSAs: o speaker D: (hash algorithm H2; key SK3), (hash algorithm H3; key SK4) o speaker E: (hash algorithm H2; key SK3), (hash algorithm H4; keys SK5 and SK6) o speaker F: (hash algorithm H3; keys SK4 and SK7), (hash algorithm H5; key SK8)
Packets sent by D would contain two HMAC TLVs each. Packets sent by E and F would contain three HMAC TLVs each. D and E would authenticate the exchange between themselves, using H2 and SK3; D and F would use H3 and SK4; E and F would discard each other's packets. The simultaneous use of H4, SK5, and SK6 by E, as well as the use of SK7, H5, and SK8 by F (for their own purposes), would remain insignificant to D. An operator implementing multi-domain authentication should keep in mind that values of MaxDigestsIn and MaxDigestsOut may be different both within the same Babel speaker and across different speakers. Since the minimum value of both parameters is 2 (see Sections 3.4 and 3.5), when more than two authentication domains are configured simultaneously it is advisable to confirm that every involved speaker can handle a sufficient number of HMAC results for both sending and receiving. The recommended method of Babel speaker configuration for multi-domain authentication is to not only use a different authentication key for each domain but also a separate CSA for each domain, even when hash algorithms are the same. This allows for fair competition between CSAs and sometimes limits the consequences of a possible misconfiguration to the scope of one CSA. See also item (f) of Section 8.7.3. Migration to and from Authenticated Exchange
It is common in practice to consider a migration to the authenticated exchange of routing information only after the network has already been deployed and put into active use. Performing the migration in a way without regular traffic interruption is typically demanded, and this specification allows a smooth migration using the RxAuthRequired interface parameter defined in Section 3.1. This measure is similar to the "transition mode" suggested in Section 5 of [OSPF3-AUTH-BIS]. An operator performing the migration needs to arrange configuration changes as follows: 1. Decide on particular hash algorithm(s) and key(s) to be used. 2. Identify all speakers and their involved interfaces that need to be migrated to authenticated exchange. 3. For each of the speakers and the interfaces to be reconfigured, first set the RxAuthRequired parameter to FALSE, then configure necessary CSA(s).
4. Examine the speakers to confirm that Babel packets are
successfully authenticated according to the configuration (for
instance, by examining ANM table entries and authentication-
specific statistics; see Figure 1 in Appendix A), and address any
discrepancies before proceeding further.
5. For each of the speakers and the reconfigured interfaces, set the
RxAuthRequired parameter to TRUE.
Likewise, temporarily setting RxAuthRequired to FALSE can be used to
migrate smoothly from an authenticated packet exchange back to an
unauthenticated one.
7.4. Handling of Authentication Key Exhaustion
This specification employs a common concept of multiple
authentication keys coexisting for a given interface, with two
independent lifetime ranges associated with each key (one for sending
and another for receiving). It is typically recommended that the
keys be configured using finite lifetimes, adding new keys before the
old keys expire. However, it is obviously possible for all keys to
expire for a given interface (for sending, receiving, or both).
Possible ways of addressing this situation raise their own concerns:
o Automatic switching to unauthenticated protocol exchange. This
behaviour invalidates the initial purposes of authentication and
is commonly viewed as unacceptable ([RIP2-AUTH] Section 5.1,
[OSPF2-AUTH] Section 3.2, and [OSPF3-AUTH-BIS] Section 3).
o Stopping routing information exchange over the interface. This
behaviour is likely to impact regular traffic routing and is
commonly viewed as "not advisable" ([RIP2-AUTH], [OSPF2-AUTH], and
[OSPF3-AUTH]), although [OSPF3-AUTH-BIS] is different in this
regard.
o The use of the "most recently expired" key over its intended
lifetime range. This behaviour is recommended for implementation
in [RIP2-AUTH], [OSPF2-AUTH], and [OSPF3-AUTH] but not in
[OSPF3-AUTH-BIS]. Such use of this key may become a problem, due
to an offline cryptographic attack (see item (f) of Section 8) or
a compromise of the key. In addition, distinguishing a recently
expired key from a key that has never been used may be impossible
after a router restart.
The design of this mechanism prevents automatic switching to
unauthenticated exchange and is consistent with similar
authentication mechanisms in this regard, but since the best choice
between two other options depends on local site policy, this decision
is left up to the operator rather than the implementor (in a way resembling the "fail secure" configuration knob described in Section 5.1 of [RIP2-AUTH]). Although the deriving procedure does not allow for any exceptions in the filtering of expired keys (Section 5.2 item 2), the operator can trivially enforce one of the two remaining behaviour options through local key-management procedures. In particular, when using the key over its intended lifetime is preferable to regular traffic disruption, the operator would explicitly leave the old key expiry time open until the new key is added to the router configuration. In the opposite case, the operator would always configure the old key with a finite lifetime and bear associated risks.8. Security Considerations
The use of this mechanism implies requirements common to the use of shared authentication keys, including, but not limited to: o holding the keys secret, o including sufficient amounts of random bits into each key, o rekeying on a regular basis, and o never reusing a used key for a different purpose. That said, proper design and implementation of a key-management policy are out of the scope of this work. Many publications on this subject exist and should be used for this purpose (BCP 107 [RFC4107], BCP 132 [RFC4962], and [RFC6039] are suggested as starting points). It is possible for a network that exercises rollover of authentication keys to experience accidental expiration of all the keys for a network interface, as discussed at greater length in Section 7.4. With that and the guidance of Section 5.1 of [RIP2-AUTH] in mind, in such an event the Babel speaker MUST send a "last key expired" notification to the operator (e.g., via syslog, SNMP, and/or other implementation-specific means), most likely in relation to item (b) of Section 5.5. Also, any actual occurrence of an authentication key expiration MUST cause a security event to be logged by the implementation. The log item MUST include at least a note that the authentication key has expired, the Babel routing protocol instance(s) affected, the network interface(s) affected, the LocalKeyID that is affected, and the current date/time. Operators are encouraged to check such logs as an operational security practice.
Considering particular attacks being in scope or out of scope on one
hand and measures taken to protect against particular in-scope
attacks on the other, the original Babel protocol and this
authentication mechanism are in line with similar datagram-based
routing protocols and their respective mechanisms. In particular,
the primary concerns addressed are:
a. Peer Entity Authentication
The Babel speaker authentication mechanism defined herein is
believed to be as strong as the class itself to which it belongs.
This specification is built on fundamental concepts implemented
for authentication of similar routing protocols: per-packet
authentication, the use of the HMAC construction, and the use of
shared keys. Although this design approach does not address all
possible concerns, it is so far known to be sufficient for most
practical cases.
b. Data Integrity
Meaningful parts of a Babel datagram are the contents of the
Babel packet (in the definition of Section 4.2 of [BABEL]) and
the source address of the datagram (Section 3.5.3 of [BABEL]).
This mechanism authenticates both parts, using the HMAC
construction, so that making any meaningful change to an
authenticated packet after it has been emitted by the sender
should be as hard as attacking the HMAC construction itself or
successfully recovering the authentication key.
Note well that any trailing data of the Babel datagram is not
meaningful in the scope of the original specification and does
not belong to the Babel packet. Integrity of the trailing data
is thus not protected by this mechanism. At the same time,
although any TLV extra data is also not meaningful in the same
scope, its integrity is protected, since this extra data is a
part of the Babel packet (see Figure 2 in Appendix A).
c. Denial of Service
Proper deployment of this mechanism in a Babel network
significantly increases the efforts required for an attacker to
feed arbitrary Babel packets into a protocol exchange (with the
intent of attacking a particular Babel speaker or disrupting the
exchange of regular traffic in a routing domain). It also
protects the neighbour table from being flooded with forged
speaker entries.
At the same time, this protection comes with a price of CPU time
being spent on HMAC computations. This may be a concern for
low-performance CPUs combined with high-speed interfaces, as
sometimes seen in embedded systems and hardware routers. The
MaxDigestsIn parameter, which is used to limit the maximum amount
of CPU time spent on a single received Babel packet, addresses
this concern to some extent.
d. Reflection Attacks
Given the approach discussed in item (b), the only potential
reflection attack on this mechanism could be replaying exact
copies of Babel packets back to the sender from the same source
address. The mitigation in this case is straightforward and is
discussed in Section 5.4.
The following in-scope concern is only partially addressed:
e. Replay Attacks
This specification establishes a basic replay protection measure
(see Section 3.6), defines a timeout parameter affecting its
strength (see Section 3.7), and outlines implementation methods
also affecting protection strength in several ways (see
Section 5.1). The implementor's choice of the timeout value and
particular implementation methods may be suboptimal due to, for
example, insufficient hardware resources of the Babel speaker.
Furthermore, it may be possible that an operator configures the
timeout and the methods to address particular local specifics,
and this further weakens the protection. An operator concerned
about replay attack protection strength should understand these
factors and their meaning in a given network segment.
That said, a particular form of replay attack on this mechanism
remains possible anyway. Whether there are two or more network
segments using the same CSA and there is an adversary that
captures Babel packets on one segment and replays on another (and
vice versa, due to the bidirectional reachability requirement for
neighbourship), some of the speakers on one such segment will
detect the "virtual" neighbours from another and may prefer them
for some destinations. This applies even more so as Babel
doesn't require a common pre-configured network prefix between
neighbours.
A reliable solution to this particular problem, which Section 4.5
of [RFC7186] discusses as well, is not currently known. It is
recommended that the operators use distinct CSAs for distinct
network segments.
The following in-scope concerns are not addressed:
f. Offline Cryptographic Attacks
This mechanism is obviously subject to offline cryptographic
attacks. As soon as an attacker has obtained a copy of an
authenticated Babel packet of interest (which gets easier to do
in wireless networks), he has all of the parameters of the
authentication-specific processing performed by the sender,
except for authentication key(s) and the choice of particular
hash algorithm(s). Since digest lengths of common hash
algorithms are well known and can be matched with those seen in
the packet, the complexity of this attack is essentially that of
the authentication key attack.
Viewing the cryptographic strength of particular hash algorithms
as a concern of its own, the main practical means of resisting
offline cryptographic attacks on this mechanism are periodic
rekeying and the use of strong keys with a sufficient number of
random bits.
It is important to understand that in the case of multiple keys
being used within a single interface (for multi-domain
authentication or during a key rollover) the strength of the
combined configuration would be that of the weakest key, since
only one successful HMAC test is required for an authentic
packet. Operators concerned about offline cryptographic attacks
should enforce the same strength policy for all keys used for a
given interface.
Note that a special pathological case is possible with this
mechanism. Whenever two or more authentication keys are
configured for a given interface such that all keys share the
same AuthKeyOctets and the same HashAlgo, but LocalKeyID modulo
2^16 is different for each key, these keys will not be treated as
duplicate (Section 5.2 item 4), but an HMAC result computed for a
given packet will be the same for each of these keys. In the
case of the sending procedure, this can produce multiple HMAC
TLVs with exactly the same value of the Digest field but
different values of the KeyID field. In this case, the attacker
will see that the keys are the same, even without knowledge of
the key itself. The reuse of authentication keys is not the
intended use case of this mechanism and should be strongly
avoided.
g. Non-repudiation
This specification relies on the use of shared keys. There is no
timestamp infrastructure and no key-revocation mechanism defined
to address the compromise of a shared key. Establishing the time
that a particular authentic Babel packet was generated is thus
not possible. Proving that a particular Babel speaker had
actually sent a given authentic packet is also impossible as soon
as the shared key is claimed compromised. Even if the shared key
is not compromised, reliably identifying the speaker that had
actually sent a given authentic Babel packet is not possible.
Since any of the speakers sharing a key can impersonate any other
speaker sharing the same key, it is only possible to prove that
the speaker belongs to the group sharing the key.
h. Confidentiality Violations
The original Babel protocol does not encrypt any of the
information contained in its packets. The contents of a Babel
packet are trivial to decode and thus can reveal network topology
details. This mechanism does not improve this situation in any
way. Since routing protocol messages are not the only kind of
information subject to confidentiality concerns, a complete
solution to this problem is likely to include measures based on
the channel security model, such as IPsec and Wi-Fi Protected
Access 2 (WPA2) at the time of this writing.
i. Key Management
Any authentication key exchange/distribution concerns are out of
scope. However, the internal representation of authentication
keys (see Section 3.8) allows implementations to use such diverse
key-management techniques as manual configuration, a provisioning
system, a key-management protocol, or any other means that comply
with this specification.
j. Message Deletion
Any message deletion attacks are out of scope. Since a datagram
deleted by an attacker cannot be distinguished from a datagram
naturally lost in transmission, and since datagram-based routing
protocols are designed to withstand a certain loss of packets,
the currently established practice is treating authentication
purely as a per-packet function, without any added detection of
lost packets.
9. IANA Considerations
At the time of publication of this document, the Babel TLV Types
namespace did not have an IANA registry. TLV types 11 and 12 were
assigned (see Table 1 in Appendix A) to the TS/PC and HMAC TLV types
by Juliusz Chroboczek, designer of the original Babel protocol.
Therefore, this document has no IANA actions.
10. Acknowledgements
Thanks to Randall Atkinson and Matthew Fanto for their comprehensive
work on [RIP2-AUTH] that initiated a series of publications on
routing protocol authentication, including this one. This
specification adopts many concepts belonging to the whole series.
Thanks to Juliusz Chroboczek, Gabriel Kerneis, and Matthieu Boutier.
This document incorporates many technical and editorial corrections
based on their feedback. Thanks to all contributors to Babel,
because this work would not be possible without the prior works.
Thanks to Dominic Mulligan for editorial proofreading of this
document. Thanks to Riku Hietamaki for suggesting the test vectors
section.
Thanks to Joel Halpern, Jim Schaad, Randall Atkinson, and Stephen
Farrell for providing (in chronological order) valuable feedback on
earlier versions of this document.
Thanks to Jim Gettys and Dave Taht for developing the CeroWrt
wireless router project and collaborating on many integration issues.
A practical need for Babel authentication emerged during research
based on CeroWrt that eventually became the very first use case of
this mechanism.
Thanks to Kunihiro Ishiguro and Paul Jakma for establishing the GNU
Zebra and Quagga routing software projects, respectively. Thanks to
Werner Koch, the author of Libgcrypt. The very first implementation
of this mechanism was made on a base of Quagga and Libgcrypt.
11. References
11.1. Normative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [FIPS-198] National Institute of Standards and Technology, "The Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 198-1, July 2008. [BABEL] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, April 2011.11.2. Informative References
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option", RFC 4030, March 2005. [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005. [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [RIP2-AUTH] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic Authentication", RFC 4822, February 2007.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007. [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008. [ISIS-AUTH-A] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008. [ISIS-AUTH-B] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009. [OSPF2-AUTH] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, October 2009. [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues with Existing Cryptographic Protection Methods for Routing Protocols", RFC 6039, October 2010. [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011. [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, March 2011. [OSPF3-AUTH] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 6506, February 2012. [RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, September 2012. [BABEL-EXTENSION] Chroboczek, J., "Extension Mechanism for the Babel Routing Protocol", Work in Progress, June 2014.
[OSPF3-AUTH-BIS] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 7166, March 2014. [RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 7183, April 2014. [RFC7186] Yi, J., Herberg, U., and T. Clausen, "Security Threats for the Neighborhood Discovery Protocol (NHDP)", RFC 7186, April 2014.
Appendix A. Figures and Tables
+-------------------------------------------------------------+ | authentication-specific statistics | +-------------------------------------------------------------+ ^ | ^ | v | | +-----------------------------------------------+ | | | system operator | | | +-----------------------------------------------+ | | ^ | ^ | ^ | ^ | ^ | | | | v | | | | | | | v | +---+ +---------+ | | | | | | +---------+ +---+ | |->| ANM | | | | | | | | LocalTS |->| | | R |<-| table | | | | | | | | LocalPC |<-| T | | x | +---------+ | v | v | v +---------+ | x | | | +----------------+ +---------+ +----------------+ | | | p | | MaxDigestsIn | | | | MaxDigestsOut | | p | | r |<-| ANM timeout | | CSAs | | |->| r | | o | | RxAuthRequired | | | | | | o | | c | +----------------+ +---------+ +----------------+ | c | | e | +-------------+ | | +-------------+ | e | | s | | Rx ESAs | | | | Tx ESAs | | s | | s |<-| (temporary) |<----+ +---->| (temporary) |->| s | | i | +-------------+ +-------------+ | i | | n | +------------------------------+----------------+ | n | | g | | instance of | output buffers |=>| g | | |=>| the original +----------------+ | | | | | protocol | source address |->| | +---+ +------------------------------+----------------+ +---+ /\ | || || v \/ +-------------------------------------------------------------+ | network stack | +-------------------------------------------------------------+ /\ || /\ || /\ || /\ || || \/ || \/ || \/ || \/ +---------+ +---------+ +---------+ +---------+ | speaker | | speaker | ... | speaker | | speaker | +---------+ +---------+ +---------+ +---------+ Flow of control data : ---> Flow of Babel datagrams/packets: ===> Figure 1: Interaction Diagram
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 | +-------+-------------------------+---------------+ Table 1: Babel TLV Types 0 through 12 +--------------+-----------------------------+-------------------+ | Packet field | Packet octets (hexadecimal) | Meaning (decimal) | +--------------+-----------------------------+-------------------+ | Magic | 2a | 42 | | Version | 02 | version 2 | | Body length | 00:14 | 20 octets | | [TLV] Type | 04 | 4 (Hello) | | [TLV] Length | 06 | 6 octets | | Reserved | 00:00 | no meaning | | Seqno | 09:25 | 2341 | | Interval | 01:90 | 400 (4.00 s) | | [TLV] Type | 08 | 8 (Update) | | [TLV] Length | 0a | 10 octets | | AE | 00 | 0 (wildcard) | | Flags | 40 | default router-id | | Plen | 00 | 0 bits | | Omitted | 00 | 0 bits | | Interval | ff:ff | infinity | | Seqno | 68:21 | 26657 | | Metric | ff:ff | infinity | +--------------+-----------------------------+-------------------+ Table 2: A Babel Packet without Authentication TLVs
+---------------+-------------------------------+-------------------+ | Packet field | Packet octets (hexadecimal) | Meaning (decimal) | +---------------+-------------------------------+-------------------+ | Magic | 2a | 42 | | Version | 02 | version 2 | | Body length | 00:4c | 76 octets | | [TLV] Type | 04 | 4 (Hello) | | [TLV] Length | 06 | 6 octets | | Reserved | 00:00 | no meaning | | Seqno | 09:25 | 2341 | | Interval | 01:90 | 400 (4.00 s) | | [TLV] Type | 08 | 8 (Update) | | [TLV] Length | 0a | 10 octets | | AE | 00 | 0 (wildcard) | | Flags | 40 | default router-id | | Plen | 00 | 0 bits | | Omitted | 00 | 0 bits | | Interval | ff:ff | infinity | | Seqno | 68:21 | 26657 | | Metric | ff:ff | infinity | | [TLV] Type | 0b | 11 (TS/PC) | | [TLV] Length | 06 | 6 octets | | PacketCounter | 00:01 | 1 | | Timestamp | 52:1d:7e:8b | 1377664651 | | [TLV] Type | 0c | 12 (HMAC) | | [TLV] Length | 16 | 22 octets | | KeyID | 00:c8 | 200 | | Digest | fe:80:00:00:00:00:00:00:0a:11 | padding | | | 96:ff:fe:1c:10:c8:00:00:00:00 | | | [TLV] Type | 0c | 12 (HMAC) | | [TLV] Length | 16 | 22 octets | | KeyID | 00:64 | 100 | | Digest | fe:80:00:00:00:00:00:00:0a:11 | padding | | | 96:ff:fe:1c:10:c8:00:00:00:00 | | +---------------+-------------------------------+-------------------+ Table 3: A Babel Packet with Each HMAC TLV Padded Using IPv6 Address fe80::0a11:96ff:fe1c:10c8
+---------------+-------------------------------+-------------------+ | Packet field | Packet octets (hexadecimal) | Meaning (decimal) | +---------------+-------------------------------+-------------------+ | Magic | 2a | 42 | | Version | 02 | version 2 | | Body length | 00:4c | 76 octets | | [TLV] Type | 04 | 4 (Hello) | | [TLV] Length | 06 | 6 octets | | Reserved | 00:00 | no meaning | | Seqno | 09:25 | 2341 | | Interval | 01:90 | 400 (4.00 s) | | [TLV] Type | 08 | 8 (Update) | | [TLV] Length | 0a | 10 octets | | AE | 00 | 0 (wildcard) | | Flags | 40 | default router-id | | Plen | 00 | 0 bits | | Omitted | 00 | 0 bits | | Interval | ff:ff | infinity | | Seqno | 68:21 | 26657 | | Metric | ff:ff | infinity | | [TLV] Type | 0b | 11 (TS/PC) | | [TLV] Length | 06 | 6 octets | | PacketCounter | 00:01 | 1 | | Timestamp | 52:1d:7e:8b | 1377664651 | | [TLV] Type | 0c | 12 (HMAC) | | [TLV] Length | 16 | 22 octets | | KeyID | 00:c8 | 200 | | Digest | c6:f1:06:13:30:3c:fa:f3:eb:5d | HMAC result | | | 60:3a:ed:fd:06:55:83:f7:ee:79 | | | [TLV] Type | 0c | 12 (HMAC) | | [TLV] Length | 16 | 22 octets | | KeyID | 00:64 | 100 | | Digest | df:32:16:5e:d8:63:16:e5:a6:4d | HMAC result | | | c7:73:e0:b5:22:82:ce:fe:e2:3c | | +---------------+-------------------------------+-------------------+ Table 4: A Babel Packet with Each HMAC TLV Containing an HMAC Result
Appendix B. Test Vectors
The test vectors below may be used to verify the correctness of some procedures performed by an implementation of this mechanism, namely: o appending TS/PC and HMAC TLVs to the Babel packet body, o padding the HMAC TLV(s), o computation of the HMAC result(s), and o placement of the result(s) in the TLV(s). This verification isn't exhaustive. There are other important implementation aspects that would require testing methods of their own. The test vectors were produced as follows. 1. A Babel speaker with a network interface with IPv6 link-local address fe80::0a11:96ff:fe1c:10c8 was configured to use two CSAs for the interface: * CSA1={HashAlgo=RIPEMD-160, KeyChain={{LocalKeyID=200, AuthKeyOctets=Key26}}} * CSA2={HashAlgo=SHA-1, KeyChain={{LocalKeyId=100, AuthKeyOctets=Key70}}} The authentication keys above are: * Key26 in ASCII: ABCDEFGHIJKLMNOPQRSTUVWXYZ * Key26 in hexadecimal: 41:42:43:44:45:46:47:48:49:4a:4b:4c:4d:4e:4f:50 51:52:53:54:55:56:57:58:59:5a * Key70 in ASCII: This=key=is=exactly=70=octets=long.=ABCDEFGHIJKLMNOPQRSTUVWXYZ01234567
* Key70 in hexadecimal:
54:68:69:73:3d:6b:65:79:3d:69:73:3d:65:78:61:63
74:6c:79:3d:37:30:3d:6f:63:74:65:74:73:3d:6c:6f
6e:67:2e:3d:41:42:43:44:45:46:47:48:49:4a:4b:4c
4d:4e:4f:50:51:52:53:54:55:56:57:58:59:5a:30:31
32:33:34:35:36:37
The length of each key was picked to relate (using the terms
listed in Section 2.4) to the properties of its respective hash
algorithm as follows:
* the digest length (L) of both RIPEMD-160 and SHA-1 is 20
octets,
* the internal block size (B) of both RIPEMD-160 and SHA-1 is 64
octets,
* the length of Key26 (26) is greater than L but less than B,
and
* the length of Key70 (70) is greater than B (and thus greater
than L).
KeyStartAccept, KeyStopAccept, KeyStartGenerate, and
KeyStopGenerate were set to make both authentication keys valid.
2. The instance of the original protocol of the speaker produced a
Babel packet (PktO) to be sent from the interface. Table 2
provides a decoding of PktO, the contents of which are below:
2a:02:00:14:04:06:00:00:09:25:01:90:08:0a:00:40
00:00:ff:ff:68:21:ff:ff
3. The authentication mechanism appended one TS/PC TLV and two HMAC
TLVs to the packet body, updated the "Body length" packet header
field, and padded the Digest field of the HMAC TLVs, using the
link-local IPv6 address of the interface and the necessary amount
of zeroes. Table 3 provides a decoding of the resulting
temporary packet (PktT), the contents of which are below:
2a:02:00:4c:04:06:00:00:09:25:01:90:08:0a:00:40
00:00:ff:ff:68:21:ff:ff:0b:06:00:01:52:1d:7e:8b
0c:16:00:c8:fe:80:00:00:00:00:00:00:0a:11:96:ff
fe:1c:10:c8:00:00:00:00:0c:16:00:64:fe:80:00:00
00:00:00:00:0a:11:96:ff:fe:1c:10:c8:00:00:00:00
4. The authentication mechanism produced two HMAC results,
performing the computations as follows:
* For H=RIPEMD-160, K=Key26, and Text=PktT, the HMAC result is:
c6:f1:06:13:30:3c:fa:f3:eb:5d:60:3a:ed:fd:06:55
83:f7:ee:79
* For H=SHA-1, K=Key70, and Text=PktT, the HMAC result is:
df:32:16:5e:d8:63:16:e5:a6:4d:c7:73:e0:b5:22:82
ce:fe:e2:3c
5. The authentication mechanism placed each HMAC result into its
respective HMAC TLV, producing the final authenticated Babel
packet (PktA), which was eventually sent from the interface.
Table 4 provides a decoding of PktA, the contents of which are
below:
2a:02:00:4c:04:06:00:00:09:25:01:90:08:0a:00:40
00:00:ff:ff:68:21:ff:ff:0b:06:00:01:52:1d:7e:8b
0c:16:00:c8:c6:f1:06:13:30:3c:fa:f3:eb:5d:60:3a
ed:fd:06:55:83:f7:ee:79:0c:16:00:64:df:32:16:5e
d8:63:16:e5:a6:4d:c7:73:e0:b5:22:82:ce:fe:e2:3c
Interpretation of this process is to be done differently for the
sending and receiving directions (see Figure 1).
For the sending direction, given a Babel speaker configured using the
IPv6 address and the sequence of CSAs as described above, the
implementation SHOULD (see notes in Section 5.3) produce exactly the
temporary packet PktT if the original protocol instance produces
exactly the packet PktO to be sent from the interface. If the
temporary packet exactly matches PktT, the HMAC results computed
afterwards MUST exactly match the respective results above, and the
final authenticated packet MUST exactly match PktA above.
For the receiving direction, given a Babel speaker configured using
the sequence of CSAs as described above (but a different IPv6
address), the implementation MUST (assuming that the TS/PC check
didn't fail) produce exactly the temporary packet PktT above if its
network stack receives through the interface exactly the packet PktA
above from the source IPv6 address above. The first HMAC result
computed afterwards MUST match the first result above. The receiving
procedure doesn't compute the second HMAC result in this case, but if
the implementor decides to compute it anyway for verification
purposes, it MUST exactly match the second result above.
Author's Address
Denis Ovsienko Yandex 16, Leo Tolstoy St. Moscow 119021 Russia EMail: infrastation@yandex.ru