tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7298


Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication

Part 3 of 3, p. 34 to 55
Prev RFC Part


prevText      Top      Up      ToC       Page 34 
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.

Top      Up      ToC       Page 35 
   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

   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)

Top      Up      ToC       Page 36 
   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

   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).

Top      Up      ToC       Page 37 
   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

   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

Top      Up      ToC       Page 38 
   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

Top      Up      ToC       Page 39 
   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.

Top      Up      ToC       Page 40 
       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

Top      Up      ToC       Page 41 
       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

Top      Up      ToC       Page 42 
       the key itself.  The reuse of authentication keys is not the
       intended use case of this mechanism and should be strongly

   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,

Top      Up      ToC       Page 43 
       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

   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.

Top      Up      ToC       Page 44 
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.

              Atkinson, R. and M. Fanto, "RIPv2 Cryptographic
              Authentication", RFC 4822, February 2007.

Top      Up      ToC       Page 45 
   [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.

              Li, T. and R. Atkinson, "IS-IS Cryptographic
              Authentication", RFC 5304, October 2008.

              Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
              and M. Fanto, "IS-IS Generic Cryptographic
              Authentication", RFC 5310, February 2009.

              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.

              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.

              Chroboczek, J., "Extension Mechanism for the Babel Routing
              Protocol", Work in Progress, June 2014.

Top      Up      ToC       Page 46 
              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.

Top      Up      ToC       Page 47 
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

Top      Up      ToC       Page 48 
   |<---------------------------->|                                 (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

   |<----------------------------------------------------->|        (D2)
   |                             B                         |
   |  |<-------------------------------------------------->|
   |  |                                                    |
   |H |some |some |   |some |some |TS/PC |HMAC  |   |HMAC  |T |
   |  |TLV  |TLV  |   |TLV  |TLV  |TLV   |TLV 1 |   |TLV n |  |
   |  |     |     |   |     |     |      |      |   |      |  |

   |<----------------------------------------------------->|        (D3)
   |                             B                         |
   |  |<-------------------------------------------------->|
   |  |                                                    |
   |H |TS/PC |HMAC  |   |HMAC  |some |some |   |some |some |T |
   |  |TLV   |TLV 1 |   |TLV n |TLV  |TLV  |   |TLV  |TLV  |  |
   |  |      |      |   |      |     |     |   |     |     |  |

   |<------------------------------------------------------------>| (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

Top      Up      ToC       Page 49 
            | 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

Top      Up      ToC       Page 50 
   | 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

Top      Up      ToC       Page 51 
   | 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

Top      Up      ToC       Page 52 
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,

       *  CSA2={HashAlgo=SHA-1, KeyChain={{LocalKeyId=100,

       The authentication keys above are:

       *  Key26 in ASCII:


       *  Key26 in hexadecimal:


       *  Key70 in ASCII:


Top      Up      ToC       Page 53 
       *  Key70 in hexadecimal:


       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

       *  the internal block size (B) of both RIPEMD-160 and SHA-1 is 64

       *  the length of Key26 (26) is greater than L but less than B,

       *  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:


   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:


Top      Up      ToC       Page 54 
   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:


       *  For H=SHA-1, K=Key70, and Text=PktT, the HMAC result is:


   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


   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.

Top      Up      ToC       Page 55 
Author's Address

   Denis Ovsienko
   16, Leo Tolstoy St.
   Moscow  119021