draft-ietf-babel-hmac-01.txt   draft-ietf-babel-hmac-02.txt 
Network Working Group C. Do Network Working Group C. Do
Internet-Draft W. Kolodziejak Internet-Draft W. Kolodziejak
Obsoletes: 7298 (if approved) J. Chroboczek Obsoletes: 7298 (if approved) J. Chroboczek
Updates: 6126bis (if approved) IRIF, University of Paris-Diderot Updates: 6126bis (if approved) IRIF, University of Paris-Diderot
Intended status: Standards Track November 14, 2018 Intended status: Standards Track December 23, 2018
Expires: May 18, 2019 Expires: June 26, 2019
HMAC authentication for the Babel routing protocol HMAC authentication for the Babel routing protocol
draft-ietf-babel-hmac-01 draft-ietf-babel-hmac-02
Abstract Abstract
This document describes a cryptographic authentication for the Babel This document describes a cryptographic authentication for the Babel
routing protocol that has provisions for replay avoidance. This routing protocol that has provisions for replay avoidance. This
document updates RFC 6126bis and obsoletes RFC 7298. document updates RFC 6126bis and obsoletes RFC 7298.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 18, 2019. This Internet-Draft will expire on June 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
1.2. Assumptions and security properties . . . . . . . . . . . 3 1.2. Assumptions and security properties . . . . . . . . . . . 3
1.3. Specification of Requirements . . . . . . . . . . . . . . 4 1.3. Specification of Requirements . . . . . . . . . . . . . . 4
2. Conceptual overview of the protocol . . . . . . . . . . . . . 4 2. Conceptual overview of the protocol . . . . . . . . . . . . . 4
3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 5 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. The Interface Table . . . . . . . . . . . . . . . . . . . 5 3.1. The Interface Table . . . . . . . . . . . . . . . . . . . 5
3.2. The Neighbour table . . . . . . . . . . . . . . . . . . . 6 3.2. The Neighbour table . . . . . . . . . . . . . . . . . . . 6
4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 6
4.1. HMAC computation . . . . . . . . . . . . . . . . . . . . 6 4.1. HMAC computation . . . . . . . . . . . . . . . . . . . . 6
4.2. Packet Transmission . . . . . . . . . . . . . . . . . . . 7 4.2. Packet Transmission . . . . . . . . . . . . . . . . . . . 7
4.3. Packet Reception . . . . . . . . . . . . . . . . . . . . 8 4.3. Packet Reception . . . . . . . . . . . . . . . . . . . . 8
5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. Expiring per-neighbour state . . . . . . . . . . . . . . 10
5.1. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. PC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. PC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 11 5.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 12
5.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 12 5.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informational References . . . . . . . . . . . . . . . . 14 9.2. Informational References . . . . . . . . . . . . . . . . 15
Appendix A. Incremental deployment and key rotation . . . . . . 15 Appendix A. Incremental deployment and key rotation . . . . . . 15
Appendix B. Changes from previous versions . . . . . . . . . . . 15 Appendix B. Changes from previous versions . . . . . . . . . . . 16
B.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 15 B.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 B.2. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
By default, the Babel routing protocol trusts the information By default, the Babel routing protocol trusts the information
contained in every UDP packet it receives on the Babel port. An contained in every UDP packet it receives on the Babel port. An
attacker can redirect traffic to itself or to a different node in the attacker can redirect traffic to itself or to a different node in the
network, causing a variety of potential issues. In particular, an network, causing a variety of potential issues. In particular, an
attacker might: attacker might:
o spoof a Babel packet, and redirect traffic by announcing a smaller o spoof a Babel packet, and redirect traffic by announcing a smaller
skipping to change at page 3, line 31 skipping to change at page 3, line 34
is inapplicable in situations where asymmetric keying is required, is inapplicable in situations where asymmetric keying is required,
where the trust relationship is partial, or where large numbers of where the trust relationship is partial, or where large numbers of
trusted keys are provisioned on a single link at the same time. trusted keys are provisioned on a single link at the same time.
This protocol supports incremental deployment (where an insecure This protocol supports incremental deployment (where an insecure
Babel network is made secure with no service interruption), and it Babel network is made secure with no service interruption), and it
supports graceful key rotation (where the set of keys is changed with supports graceful key rotation (where the set of keys is changed with
no service interruption). no service interruption).
This protocol does not require synchronised clocks, it does not This protocol does not require synchronised clocks, it does not
require persistently monotonic clocks, and it does not require any require persistently monotonic clocks, and it does not require
form of persistent storage. persistent storage except for what might be required for storing
cryptographic keys.
1.2. Assumptions and security properties 1.2. Assumptions and security properties
The correctness of the protocol relies on the following assumptions: The correctness of the protocol relies on the following assumptions:
o that the Hashed Message Authentication Code (HMAC) being used is o that the Hashed Message Authentication Code (HMAC) being used is
invulnerable to pre-image attacks, i.e., that an attacker is invulnerable to pre-image attacks, i.e., that an attacker is
unable to generate a packet with a correct HMAC; unable to generate a packet with a correct HMAC;
o that a node never generates the same index or nonce twice over the o that a node never generates the same index or nonce twice over the
skipping to change at page 4, line 52 skipping to change at page 5, line 9
In order to protect against replay B maintains a per-interface 32-bit In order to protect against replay B maintains a per-interface 32-bit
integer known as the "packet counter" (PC). Whenever B sends a integer known as the "packet counter" (PC). Whenever B sends a
packet through the interface, it embeds the current value of the PC packet through the interface, it embeds the current value of the PC
within the region of the packet that is protected by the HMACs and within the region of the packet that is protected by the HMACs and
increases the PC by at least one. When A receives the packet, it increases the PC by at least one. When A receives the packet, it
compares the value of the PC with the one contained in the previous compares the value of the PC with the one contained in the previous
packet received from B, and unless it is strictly greater, the packet packet received from B, and unless it is strictly greater, the packet
is discarded. is discarded.
By itself, the PC mechanism is not sufficient to protect against By itself, the PC mechanism is not sufficient to protect against
replay. Consider a peer A that has no information about a pair B replay. Consider a peer A that has no information about a peer B
(e.g., because it has recently rebooted). Suppose that A receives a (e.g., because it has recently rebooted). Suppose that A receives a
packet ostensibly from B carrying a given PC; since A has no packet ostensibly from B carrying a given PC; since A has no
information about B, it has no way to determine whether the packet is information about B, it has no way to determine whether the packet is
freshly generated or a replay of a previously sent packet. freshly generated or a replay of a previously sent packet.
In this situation, A discards the packet and challenges B to prove In this situation, A discards the packet and challenges B to prove
that it knows the HMAC key. It sends a "challenge request", a TLV that it knows the HMAC key. It sends a "challenge request", a TLV
containing a unique nonce, a value that has never been used before containing a unique nonce, a value that has never been used before
and will never be used again. B replies to the challenge request and will never be used again. B replies to the challenge request
with a "challenge reply", a TLV containing a copy of the nonce chosen with a "challenge reply", a TLV containing a copy of the nonce chosen
skipping to change at page 7, line 28 skipping to change at page 7, line 28
Src port The source UDP port number of the packet. Src port The source UDP port number of the packet.
Dest address The destination IP address of the packet. Dest address The destination IP address of the packet.
Src port The destination UDP port number of the packet. Src port The destination UDP port number of the packet.
The node takes the concatenation of the pseudo-header and the packet The node takes the concatenation of the pseudo-header and the packet
including the packet header but excluding the packet trailer (from including the packet header but excluding the packet trailer (from
octet 0 inclusive up to Body Length + 4 exclusive) and computes an octet 0 inclusive up to Body Length + 4 exclusive) and computes an
HMAC as defined in Section 2 of [RFC2104] with one of the implemented HMAC with one of the implemented hash algorithms. Every
hash algorithms. Every implementation MUST implement HMAC-SHA256 implementation MUST implement HMAC-SHA256 as defined in [RFC6234] and
[RFC6234], and MAY implement other HMAC algorithms. Section 2 of [RFC2104], SHOULD implement keyed BLAKE2s [RFC7693], and
MAY implement other HMAC algorithms.
4.2. Packet Transmission 4.2. Packet Transmission
A Babel node may delay actually sending TLVs by a small amount, in A Babel node may delay actually sending TLVs by a small amount, in
order to aggregate multiple TLVs in a single packet up to the order to aggregate multiple TLVs in a single packet up to the
interface MTU (Section 4 of [RFC6126bis]). For an interface on which interface MTU (Section 4 of [RFC6126bis]). For an interface on which
HMAC protection is configured, the TLV aggregation logic MUST take HMAC protection is configured, the TLV aggregation logic MUST take
into account the overhead due to PC TLVs (one in each packet) and into account the overhead due to PC TLVs (one in each packet) and
HMAC TLVs (one per configured key). HMAC TLVs (one per configured key).
skipping to change at page 10, line 37 skipping to change at page 10, line 37
neighbour that sent the Challenge Reply. If no challenge is in neighbour that sent the Challenge Reply. If no challenge is in
progress, i.e., if there is no Nonce stored in the Neighbour progress, i.e., if there is no Nonce stored in the Neighbour
Table entry or the Challenge timer has expired, the Challenge Reply Table entry or the Challenge timer has expired, the Challenge Reply
is silently ignored and the challenge has failed. is silently ignored and the challenge has failed.
Otherwise, the node compares the Nonce contained in the Challenge Otherwise, the node compares the Nonce contained in the Challenge
Reply with the Nonce contained in the Neighbour Table entry. If the Reply with the Nonce contained in the Neighbour Table entry. If the
two are equal (they have the same length and content), then the two are equal (they have the same length and content), then the
challenge has succeeded; otherwise, the challenge has failed. challenge has succeeded; otherwise, the challenge has failed.
4.4. Expiring per-neighbour state
The per-neighbour (Index, PC) pair is maintained in the neighbour
table, and is normally discarded when the neighbour table entry
expires. Implementations MUST ensure that an (Index, PC) pair is
discarded within a finite time since the last time a packet has been
accepted. In particular, unsuccessful challenges MUST NOT prevent an
(Index, PC) pair from being discarded for unbounded periods of time.
Implementations that use a Hello history (Appendix A of [RFC6126bis])
may discard the (Index, PC) pair whenever the Hello history becomes
empty. Other impementations may use a timer that is reset whenever a
packet is accepted, and discard the (Index, PC) pair whenever the
timer expires (an timeout of 5 min is suggested).
5. Packet Format 5. Packet Format
5.1. HMAC TLV 5.1. HMAC TLV
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | HMAC... | Type | Length | HMAC...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
skipping to change at page 12, line 40 skipping to change at page 13, line 9
fields. The length of the body is set to the same size as fields. The length of the body is set to the same size as
the challenge request TLV length received. the challenge request TLV length received.
Nonce A copy of the nonce contained in the corresponding Nonce A copy of the nonce contained in the corresponding
challenge request. challenge request.
6. Security Considerations 6. Security Considerations
This document defines a mechanism that provides basic security This document defines a mechanism that provides basic security
properties for the Babel routing protocol. The scope of this properties for the Babel routing protocol. The scope of this
protocol is strictly limited: it only provides authentication, on the protocol is strictly limited: it only provides authentication (we
assumption that routing information is not confidential, only assume that routing information is not confidential), it only
symmetric keying, and only allows for the use of a small number of supports symmetric keying, and it only allows for the use of a small
symmetric keys on each link. Deployments that need more features, number of symmetric keys on every link. Deployments that need more
e.g., confidentiality or asymmetric keying, should use a more features, e.g., confidentiality or asymmetric keying, should use a
featureful security mechanism such as the one described in more featureful security mechanism such as the one described in
[I-D.ietf-babel-dtls]. [I-D.ietf-babel-dtls].
This mechanism relies on two assumptions, as described in This mechanism relies on two assumptions, as described in
Section 1.2. First, it assumes that the hash being used is Section 1.2. First, it assumes that the hash being used is
invulnerable to pre-image attacks (Section 1.1 of [RFC6039]); at the invulnerable to pre-image attacks (Section 1.1 of [RFC6039]); at the
time of writing, SHA-256, which is mandatory to implement time of writing, SHA-256, which is mandatory to implement
(Section 4.1), is believed to be safe against practical attacks. (Section 4.1), is believed to be safe against practical attacks.
Second, it assumes that indices and nonces are generated uniquely Second, it assumes that indices and nonces are generated uniquely
over the lifetime of a key used for HMAC computation. This property over the lifetime of a key used for HMAC computation (more precisely,
can be satisfied either by using a cryptographically secure random indices must be unique for a given (key, source) pair, and nonces
number generator to generate indices and nonces that contain enough must be unique for a given (key, source, destination) triple). This
entropy (64-bit values are believed to be large enough for all property can be satisfied either by using a cryptographically secure
random number generator to generate indices and nonces that contain
enough entropy (64-bit values are believed to be large enough for all
practical applications), or by using a reliably monotonic hardware practical applications), or by using a reliably monotonic hardware
clock. If unicity cannot be guaranteed (e.g., because a hardware clock. If unicity cannot be guaranteed (e.g., because a hardware
clock has been reset), then rekeying is necessary. clock has been reset), then rekeying is necessary.
The expiry mechanism mandated in Section 4.4 is required to prevent
an attacker from delaying an authentic packet by an unbounded amount
of time. If an attacker is able to delay the delivery of a packet
(e.g., because it is located at a layer 2 switch), then the packet
will be accepted as long as the corresponding (Index, PC) pair is
present at the receiver. If the attacker is able to cause the
(Index, PC) pair to persist for arbitrary amounts of time (e.g., by
causing failed challenges), then it is able to delay the packet by
arbitrary amounts of time, even after the sender has left the
network.
While it is probably not possible to be immune against denial of While it is probably not possible to be immune against denial of
service (DoS) attacks in general, this protocol includes a number of service (DoS) attacks in general, this protocol includes a number of
mechanisms designed to mitigate such attacks. In particular, mechanisms designed to mitigate such attacks. In particular,
reception of a packet with no correct HMAC creates no local state reception of a packet with no correct HMAC creates no local state
whatsoever (Section 4.3). Reception of a replayed packet with whatsoever (Section 4.3). Reception of a replayed packet with
correct hash, on the other hand, causes a challenge to be sent; this correct hash, on the other hand, causes a challenge to be sent; this
is mitigated somewhat by requiring that challenges be rate-limited. is mitigated somewhat by requiring that challenges be rate-limited.
At first sight, sending a challenge requires retaining enough At first sight, sending a challenge requires retaining enough
information to validate the challenge reply. However, the nonce information to validate the challenge reply. However, the nonce
skipping to change at page 13, line 52 skipping to change at page 14, line 35
| | | | | | | |
| TBD | Challenge Reply | this document | | TBD | Challenge Reply | this document |
+------+-------------------+---------------+ +------+-------------------+---------------+
8. Acknowledgments 8. Acknowledgments
The protocol described in this document is based on the original HMAC The protocol described in this document is based on the original HMAC
protocol defined by Denis Ovsienko [RFC7298]. The use of a pseudo- protocol defined by Denis Ovsienko [RFC7298]. The use of a pseudo-
header was suggested by David Schinazi. The use of an index to avoid header was suggested by David Schinazi. The use of an index to avoid
replay was suggested by Markus Stenberg. The authors are also replay was suggested by Markus Stenberg. The authors are also
indebted to Florian Horn and Toke Hoyland-Jorgensen. indebted to Toke Hoiland-Jorgensen, Florian Horn, and Dave Taht.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997. DOI 10.17487/RFC2119, March 1997.
[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues
with Existing Cryptographic Protection Methods for Routing
Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010,
<https://www.rfc-editor.org/info/rfc6039>.
[RFC6126bis] [RFC6126bis]
Chroboczek, J. and D. Schinazi, "The Babel Routing Chroboczek, J. and D. Schinazi, "The Babel Routing
Protocol", draft-ietf-babel-rfc6126bis-06 (work in Protocol", draft-ietf-babel-rfc6126bis-06 (work in
progress), October 2018. progress), October 2018.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>. <https://www.rfc-editor.org/info/rfc6234>.
[RFC7693] Saarinen, M-J., Ed. and J-P. Aumasson, "The BLAKE2
Cryptographic Hash and Message Authentication Code (MAC)",
RFC 7693, DOI 10.17487/RFC7693, November 2015,
<https://www.rfc-editor.org/info/rfc7693>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017. May 2017.
9.2. Informational References 9.2. Informational References
[I-D.ietf-babel-dtls] [I-D.ietf-babel-dtls]
Decimo, A., Schinazi, D., and J. Chroboczek, "Babel Decimo, A., Schinazi, D., and J. Chroboczek, "Babel
Routing Protocol over Datagram Transport Layer Security", Routing Protocol over Datagram Transport Layer Security",
draft-ietf-babel-dtls-01 (work in progress), October 2018. draft-ietf-babel-dtls-01 (work in progress), October 2018.
[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues
with Existing Cryptographic Protection Methods for Routing
Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010,
<https://www.rfc-editor.org/info/rfc6039>.
[RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code
(HMAC) Cryptographic Authentication", RFC 7298, (HMAC) Cryptographic Authentication", RFC 7298,
DOI 10.17487/RFC7298, July 2014, DOI 10.17487/RFC7298, July 2014,
<https://www.rfc-editor.org/info/rfc7298>. <https://www.rfc-editor.org/info/rfc7298>.
Appendix A. Incremental deployment and key rotation Appendix A. Incremental deployment and key rotation
This protocol supports incremental deployment (transitioning from an This protocol supports incremental deployment (transitioning from an
insecure network to a secured network with no service interruption) insecure network to a secured network with no service interruption)
and key rotation (transitioning from a set of keys to a different set and key rotation (transitioning from a set of keys to a different set
skipping to change at page 15, line 44 skipping to change at page 16, line 31
o Removed the appendix about the packet trailer, this is now in o Removed the appendix about the packet trailer, this is now in
rfc6126bis. rfc6126bis.
o Removed the appendix with implicit indices. o Removed the appendix with implicit indices.
o Clarified the definitions of acronyms. o Clarified the definitions of acronyms.
o Limited the size of nonces and indices. o Limited the size of nonces and indices.
B.2. Changes since draft-ietf-babel-hmac-00
o Made BLAKE2s a recommended HMAC algorithm.
o Added requirement to expire per-neighbour crypto state.
Authors' Addresses Authors' Addresses
Clara Do Clara Do
IRIF, University of Paris-Diderot IRIF, University of Paris-Diderot
75205 Paris Cedex 13 75205 Paris Cedex 13
France France
Email: clarado_perso@yahoo.fr Email: clarado_perso@yahoo.fr
Weronika Kolodziejak Weronika Kolodziejak
IRIF, University of Paris-Diderot IRIF, University of Paris-Diderot
75205 Paris Cedex 13 75205 Paris Cedex 13
France France
Email: weronika.kolodziejak@gmail.com Email: weronika.kolodziejak@gmail.com
Juliusz Chroboczek Juliusz Chroboczek
IRIF, University of Paris-Diderot IRIF, University of Paris-Diderot
Case 7014 Case 7014
75205 Paris Cedex 13 75205 Paris Cedex 13
France France
Email: jch@irif.fr Email: jch@irif.fr
 End of changes. 22 change blocks. 
37 lines changed or deleted 80 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/