< draft-ietf-babel-hmac-07.txt   draft-ietf-babel-hmac-08.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
Intended status: Standards Track IRIF, University of Paris-Diderot Intended status: Standards Track IRIF, University of Paris-Diderot
Expires: December 22, 2019 June 20, 2019 Expires: January 8, 2020 July 7, 2019
HMAC authentication for the Babel routing protocol HMAC authentication for the Babel routing protocol
draft-ietf-babel-hmac-07 draft-ietf-babel-hmac-08
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
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 33 skipping to change at page 1, line 33
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 December 22, 2019. This Internet-Draft will expire on January 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 26 skipping to change at page 2, line 26
4.1. HMAC computation . . . . . . . . . . . . . . . . . . . . 7 4.1. HMAC computation . . . . . . . . . . . . . . . . . . . . 7
4.2. Packet Transmission . . . . . . . . . . . . . . . . . . . 8 4.2. Packet Transmission . . . . . . . . . . . . . . . . . . . 8
4.3. Packet Reception . . . . . . . . . . . . . . . . . . . . 8 4.3. Packet Reception . . . . . . . . . . . . . . . . . . . . 8
4.4. Expiring per-neighbour state . . . . . . . . . . . . . . 12 4.4. Expiring per-neighbour state . . . . . . . . . . . . . . 12
5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. PC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. PC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 13 5.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 13
5.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 14 5.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informational References . . . . . . . . . . . . . . . . 17 9.2. Informational References . . . . . . . . . . . . . . . . 17
Appendix A. Incremental deployment and key rotation . . . . . . 17 Appendix A. Incremental deployment and key rotation . . . . . . 18
Appendix B. Changes from previous versions . . . . . . . . . . . 18 Appendix B. Changes from previous versions . . . . . . . . . . . 18
B.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 18 B.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 18
B.2. Changes since draft-ietf-babel-hmac-01 . . . . . . . . . 18 B.2. Changes since draft-ietf-babel-hmac-01 . . . . . . . . . 18
B.3. Changes since draft-ietf-babel-hmac-02 . . . . . . . . . 18 B.3. Changes since draft-ietf-babel-hmac-02 . . . . . . . . . 19
B.4. Changes since draft-ietf-babel-hmac-03 . . . . . . . . . 18 B.4. Changes since draft-ietf-babel-hmac-03 . . . . . . . . . 19
B.5. Changes since draft-ietf-babel-hmac-04 . . . . . . . . . 19 B.5. Changes since draft-ietf-babel-hmac-04 . . . . . . . . . 19
B.6. Changes since draft-ietf-babel-hmac-05 . . . . . . . . . 19 B.6. Changes since draft-ietf-babel-hmac-05 . . . . . . . . . 19
B.7. Changes since draft-ietf-babel-hmac-06 . . . . . . . . . 19 B.7. Changes since draft-ietf-babel-hmac-06 . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 B.8. Changes since draft-ietf-babel-hmac-07 . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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 datagram that it receives on the Babel port. contained in every UDP datagram that it receives on the Babel port.
An attacker can redirect traffic to itself or to a different node in An attacker can redirect traffic to itself or to a different node in
the network, causing a variety of potential issues. In particular, the network, causing a variety of potential issues. In particular,
an attacker might: an 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 9, line 19 skipping to change at page 9, line 19
HMAC of the packet. It then compares every generated HMAC against HMAC of the packet. It then compares every generated HMAC against
every HMAC included in the packet; if there is at least one match, every HMAC included in the packet; if there is at least one match,
the packet passes the HMAC test; if there is none, the packet MUST the packet passes the HMAC test; if there is none, the packet MUST
be silently dropped and processing stops at this point. In order be silently dropped and processing stops at this point. In order
to avoid memory exhaustion attacks, an entry in the Neighbour to avoid memory exhaustion attacks, an entry in the Neighbour
Table MUST NOT be created before the HMAC test has passed Table MUST NOT be created before the HMAC test has passed
successfully. The HMAC of the packet MUST NOT be computed for successfully. The HMAC of the packet MUST NOT be computed for
each HMAC TLV contained in the packet, but only once for each each HMAC TLV contained in the packet, but only once for each
configured key. configured key.
o If an entry for the sender does not exist in the Neighbour Table,
it MAY be created at this point (or, alternatively, its creation
can be delayed until a challenge needs to be sent, see below);
o The packet body is then parsed a first time. During this o The packet body is then parsed a first time. During this
"preparse" phase, the packet body is traversed and all TLVs are "preparse" phase, the packet body is traversed and all TLVs are
ignored except PC TLVs, Challenge Requests and Challenge Replies. ignored except PC TLVs, Challenge Requests and Challenge Replies.
When a PC TLV is encountered, the enclosed PC and Index are saved When a PC TLV is encountered, the enclosed PC and Index are saved
for later processing; if multiple PCs are found (which should not for later processing; if multiple PCs are found (which should not
happen, see Section 4.2 above), only the first one is processed, happen, see Section 4.2 above), only the first one is processed,
the remaining ones MUST be silently ignored. If a Challenge the remaining ones MUST be silently ignored. If a Challenge
Request is encountered, a Challenge Reply MUST be scheduled, as Request is encountered, a Challenge Reply MUST be scheduled, as
described in Section 4.3.1.2. If a Challenge Reply is described in Section 4.3.1.2. If a Challenge Reply is
encountered, it is tested for validity as described in encountered, it is tested for validity as described in
Section 4.3.1.3 and a note is made of the result of the test. Section 4.3.1.3 and a note is made of the result of the test.
o The preparse phase above has yielded two pieces of data: the PC o The preparse phase above has yielded two pieces of data: the PC
and Index from the first PC TLV, and a bit indicating whether the and Index from the first PC TLV, and a bit indicating whether the
packet contains a successful Challenge Reply. If the packet does packet contains a successful Challenge Reply. If the packet does
not contain a PC TLV, the packet MUST be dropped and processing not contain a PC TLV, the packet MUST be dropped and processing
stops at this point. If the packet contains a successful stops at this point. If the packet contains a successful
Challenge Reply, then the PC and Index contained in the PC TLV Challenge Reply, then the PC and Index contained in the PC TLV
MUST be stored in the Neighbour Table entry corresponding to the MUST be stored in the Neighbour Table entry corresponding to the
sender (which may need to be created at this stage), and the sender (which already exists in this case), and the packet is
packet is accepted. accepted.
o Otherwise, if there is no entry in the Neighbour o Otherwise, if there is no entry in the Neighbour
Table corresponding to the sender, or if such an entry exists but Table corresponding to the sender, or if such an entry exists but
contains no Index, or if the Index it contains is different from contains no Index, or if the Index it contains is different from
the Index contained in the PC TLV, then a challenge MUST be sent the Index contained in the PC TLV, then a challenge MUST be sent
as described in Section 4.3.1.1, the packet MUST be dropped, and as described in Section 4.3.1.1, the packet MUST be dropped, and
processing stops at this stage. processing stops at this stage.
o At this stage, the packet contains no successful challenge reply o At this stage, the packet contains no successful challenge reply
and the Index contained in the PC TLV is equal to the Index in the and the Index contained in the PC TLV is equal to the Index in the
skipping to change at page 15, line 28 skipping to change at page 15, line 35
repeatedly causing failed challenges), then it is able to delay the repeatedly causing failed challenges), then it is able to delay the
packet by arbitrary amounts of time, even after the sender has left packet by arbitrary amounts of time, even after the sender has left
the network. 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
(Section 4.3.1.1).
At first sight, sending a challenge requires retaining enough Receiving a replayed packet with an obsolete index causes an entry to
information to validate the challenge reply. However, the nonce be created in the Neighbour Table, which, at first sight, makes the
included in a challenge request and echoed in the challenge reply can protocol susceptible to resource exhaustion attacks (similarly to the
be fairly large (up to 192 octets), which should in principle permit familiar "TCP SYN Flooding" attack [RFC4987]). However, the HMAC
computation includes the sender address (Section 4.1), and thus the
amount of storage that an attacker can force a node to consume is
limited by the number of distinct source addresses used with a single
HMAC key (see also Section 4 of [RFC6126bis], which mandates that the
source address is a link-local IPv6 address or a local IPv4 address).
In order to make this kind of resource exhaustion attacks less
effective, implementations may use a separate table of uncompleted
challenges that is separate from the Neighbour Table used by the core
protocol (the data structures described in Section 3.2 of
[RFC6126bis] are conceptual, any data structure that yields the same
result may be used). Implementers might also consider using the fact
that the nonces included in challenge requests and responses can be
fairly large (up to 192 octets), which should in principle allow
encoding the per-challenge state as a secure "cookie" within the encoding the per-challenge state as a secure "cookie" within the
nonce itself. nonce itself.
7. IANA Considerations 7. IANA Considerations
IANA has allocated the following values in the Babel TLV Types IANA has allocated the following values in the Babel TLV Types
registry: registry:
+------+-------------------+---------------+ +------+-------------------+---------------+
| Type | Name | Reference | | Type | Name | Reference |
skipping to change at page 17, line 14 skipping to change at page 17, line 29
[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-07 (work in progress), July 2019.
[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,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>. <http://www.rfc-editor.org/info/rfc4086>.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
<https://www.rfc-editor.org/info/rfc4987>.
[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues
with Existing Cryptographic Protection Methods for Routing with Existing Cryptographic Protection Methods for Routing
Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010, Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010,
<https://www.rfc-editor.org/info/rfc6039>. <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>.
skipping to change at page 19, line 23 skipping to change at page 19, line 42
o Clarify that indices and nonces of length 0 are valid. o Clarify that indices and nonces of length 0 are valid.
o Clarify that multiple PC TLVs in a single packet are not allowed. o Clarify that multiple PC TLVs in a single packet are not allowed.
o Allow discarding challenge requests when they carry an old PC. o Allow discarding challenge requests when they carry an old PC.
B.7. Changes since draft-ietf-babel-hmac-06 B.7. Changes since draft-ietf-babel-hmac-06
o Do not update RFC 6126bis, for real this time. o Do not update RFC 6126bis, for real this time.
B.8. Changes since draft-ietf-babel-hmac-07
o Clarify that a Neighbour Table entry may be created just after the
HMAC has been computed.
o Clarify that a Neighbour Table entry already exists when a
successful Challenge Reply has been received.
o Expand the Security Considerations section with information about
resource exhaustion attacks.
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
 End of changes. 14 change blocks. 
16 lines changed or deleted 52 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/