rfc8967v3.txt   rfc8967.txt 
Internet Engineering Task Force (IETF) C. Do Internet Engineering Task Force (IETF) C. Dô
Request for Comments: 8967 W. Kolodziejak Request for Comments: 8967 W. Kolodziejak
Obsoletes: 7298 J. Chroboczek Obsoletes: 7298 J. Chroboczek
Category: Standards Track IRIF, University of Paris-Diderot Category: Standards Track IRIF, University of Paris-Diderot
ISSN: 2070-1721 December 2020 ISSN: 2070-1721 January 2021
MAC Authentication for the Babel Routing Protocol MAC Authentication for the Babel Routing Protocol
Abstract Abstract
This document describes a cryptographic authentication mechanism for This document describes a cryptographic authentication mechanism for
the Babel routing protocol that has provisions for replay avoidance. the Babel routing protocol that has provisions for replay avoidance.
This document obsoletes RFC 7298. This document obsoletes RFC 7298.
Status of This Memo Status of This Memo
skipping to change at line 32 skipping to change at line 32
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841. Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8967. https://www.rfc-editor.org/info/rfc8967.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at line 165 skipping to change at line 165
will only accept a copy of that packet if B has accepted an older will only accept a copy of that packet if B has accepted an older
packet from C, and B has received no later packet from C. packet from C, and B has received no later packet from C.
While this protocol makes efforts to mitigate the effects of a denial While this protocol makes efforts to mitigate the effects of a denial
of service attack, it does not fully protect against such attacks. of service attack, it does not fully protect against such attacks.
1.3. Specification of Requirements 1.3. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in BCP
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Conceptual Overview of the Protocol 2. Conceptual Overview of the Protocol
When a node B sends out a Babel packet through an interface that is When a node B sends out a Babel packet through an interface that is
configured for MAC cryptographic protection, it computes one or more configured for MAC cryptographic protection, it computes one or more
MACs (one per key) that it appends to the packet. When a node A MACs (one per key) that it appends to the packet. When a node A
receives a packet over an interface that requires MAC cryptographic receives a packet over an interface that requires MAC cryptographic
protection, it independently computes a set of MACs and compares them protection, it independently computes a set of MACs and compares them
to the MACs appended to the packet; if there is no match, the packet to the MACs appended to the packet; if there is no match, the packet
skipping to change at line 803 skipping to change at line 803
[RFC7693] Saarinen, M-J., Ed. and J-P. Aumasson, "The BLAKE2 [RFC7693] Saarinen, M-J., Ed. and J-P. Aumasson, "The BLAKE2
Cryptographic Hash and Message Authentication Code (MAC)", Cryptographic Hash and Message Authentication Code (MAC)",
RFC 7693, DOI 10.17487/RFC7693, November 2015, RFC 7693, DOI 10.17487/RFC7693, November 2015,
<https://www.rfc-editor.org/info/rfc7693>. <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, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8966] Chroboczek, J. and D. Schinazi, "The Babel Routing [RFC8966] Chroboczek, J. and D. Schinazi, "The Babel Routing
Protocol", RFC 8966, DOI 10.17487/RFC8966, November 2020, Protocol", RFC 8966, DOI 10.17487/RFC8966, January 2021,
<https://www.rfc-editor.org/info/rfc8966>. <https://www.rfc-editor.org/info/rfc8966>.
9.2. Informational References 9.2. Informational References
[BCRYPT] Niels, P. and D. Mazières, "A Future-Adaptable Password [BCRYPT] Niels, P. and D. Mazières, "A Future-Adaptable Password
Scheme", Proceedings of the FREENIX Track: 1999 USENIX Scheme", Proceedings of the FREENIX Track: 1999 USENIX
Annual Technical Conference, June 1999. Annual Technical Conference, June 1999.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
skipping to change at line 842 skipping to change at line 842
Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914,
August 2016, <https://www.rfc-editor.org/info/rfc7914>. August 2016, <https://www.rfc-editor.org/info/rfc7914>.
[RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5: [RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5:
Password-Based Cryptography Specification Version 2.1", Password-Based Cryptography Specification Version 2.1",
RFC 8018, DOI 10.17487/RFC8018, January 2017, RFC 8018, DOI 10.17487/RFC8018, January 2017,
<https://www.rfc-editor.org/info/rfc8018>. <https://www.rfc-editor.org/info/rfc8018>.
[RFC8968] Décimo, A., Schinazi, D., and J. Chroboczek, "Babel [RFC8968] Décimo, A., Schinazi, D., and J. Chroboczek, "Babel
Routing Protocol over Datagram Transport Layer Security", Routing Protocol over Datagram Transport Layer Security",
RFC 8968, DOI 10.17487/RFC8968, November 2020, RFC 8968, DOI 10.17487/RFC8968, January 2021,
<https://www.rfc-editor.org/info/rfc8968>. <https://www.rfc-editor.org/info/rfc8968>.
Acknowledgments 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 Antonin Décimo, Donald Eastlake, Toke Høiland-Jørgensen, indebted to Antonin Décimo, Donald Eastlake, Toke Høiland-Jørgensen,
Florian Horn, Benjamin Kaduk, Dave Taht, and Martin Vigoureux. Florian Horn, Benjamin Kaduk, Dave Taht, and Martin Vigoureux.
Authors' Addresses Authors' Addresses
Clara Do Clara Dô
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
 End of changes. 7 change blocks. 
8 lines changed or deleted 8 lines changed or added

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