Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7298

Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication

Pages: 55
Obsoleted by:  8967
Updates:  6126
Part 3 of 3 – Pages 34 to 55
First   Prev   None

Top   ToC   RFC7298 - Page 34   prevText

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   ToC   RFC7298 - 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 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)
Top   ToC   RFC7298 - 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
   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).
Top   ToC   RFC7298 - 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 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
Top   ToC   RFC7298 - 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 practice.
Top   ToC   RFC7298 - 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   ToC   RFC7298 - 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
       neighbours.
Top   ToC   RFC7298 - 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   ToC   RFC7298 - Page 42
       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,
Top   ToC   RFC7298 - 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 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.
Top   ToC   RFC7298 - 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. [RIP2-AUTH] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic Authentication", RFC 4822, February 2007.
Top   ToC   RFC7298 - 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.

   [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.
Top   ToC   RFC7298 - Page 46
   [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.
Top   ToC   RFC7298 - 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   ToC   RFC7298 - Page 48
                  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
Top   ToC   RFC7298 - 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   ToC   RFC7298 - 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
                         fe80::0a11:96ff:fe1c:10c8
Top   ToC   RFC7298 - 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   ToC   RFC7298 - 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, 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
Top   ToC   RFC7298 - Page 53
       *  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
Top   ToC   RFC7298 - 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:

          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.
Top   ToC   RFC7298 - Page 55

Author's Address

Denis Ovsienko Yandex 16, Leo Tolstoy St. Moscow 119021 Russia EMail: infrastation@yandex.ru