--- 1/draft-ietf-babel-hmac-07.txt 2019-07-07 09:13:14.423931915 -0700 +++ 2/draft-ietf-babel-hmac-08.txt 2019-07-07 09:13:14.467932891 -0700 @@ -1,19 +1,19 @@ Network Working Group C. Do Internet-Draft W. Kolodziejak Obsoletes: 7298 (if approved) J. Chroboczek 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 - draft-ietf-babel-hmac-07 + draft-ietf-babel-hmac-08 Abstract This document describes a cryptographic authentication mechanism for the Babel routing protocol that has provisions for replay avoidance. This document obsoletes RFC 7298. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -22,21 +22,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -60,35 +60,36 @@ 4.1. HMAC computation . . . . . . . . . . . . . . . . . . . . 7 4.2. Packet Transmission . . . . . . . . . . . . . . . . . . . 8 4.3. Packet Reception . . . . . . . . . . . . . . . . . . . . 8 4.4. Expiring per-neighbour state . . . . . . . . . . . . . . 12 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2. PC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 13 5.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 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 B.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 18 B.2. Changes since draft-ietf-babel-hmac-01 . . . . . . . . . 18 - B.3. Changes since draft-ietf-babel-hmac-02 . . . . . . . . . 18 - B.4. Changes since draft-ietf-babel-hmac-03 . . . . . . . . . 18 + B.3. Changes since draft-ietf-babel-hmac-02 . . . . . . . . . 19 + B.4. Changes since draft-ietf-babel-hmac-03 . . . . . . . . . 19 B.5. Changes since draft-ietf-babel-hmac-04 . . . . . . . . . 19 B.6. Changes since draft-ietf-babel-hmac-05 . . . . . . . . . 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 By default, the Babel routing protocol trusts the information 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 the network, causing a variety of potential issues. In particular, an attacker might: o spoof a Babel packet, and redirect traffic by announcing a smaller @@ -383,41 +384,45 @@ HMAC of the packet. It then compares every generated HMAC against 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 be silently dropped and processing stops at this point. In order to avoid memory exhaustion attacks, an entry in the Neighbour Table MUST NOT be created before the HMAC test has passed successfully. The HMAC of the packet MUST NOT be computed for each HMAC TLV contained in the packet, but only once for each 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 "preparse" phase, the packet body is traversed and all TLVs are ignored except PC TLVs, Challenge Requests and Challenge Replies. When a PC TLV is encountered, the enclosed PC and Index are saved for later processing; if multiple PCs are found (which should not happen, see Section 4.2 above), only the first one is processed, the remaining ones MUST be silently ignored. If a Challenge Request is encountered, a Challenge Reply MUST be scheduled, as described in Section 4.3.1.2. If a Challenge Reply is 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. 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 packet contains a successful Challenge Reply. If the packet does not contain a PC TLV, the packet MUST be dropped and processing stops at this point. If the packet contains a successful Challenge Reply, then the PC and Index contained in the PC TLV MUST be stored in the Neighbour Table entry corresponding to the - sender (which may need to be created at this stage), and the - packet is accepted. + sender (which already exists in this case), and the packet is + accepted. o Otherwise, if there is no entry in the Neighbour Table corresponding to the sender, or if such an entry exists but 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 as described in Section 4.3.1.1, the packet MUST be dropped, and processing stops at this stage. 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 @@ -678,26 +683,42 @@ repeatedly 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 service (DoS) attacks in general, this protocol includes a number of mechanisms designed to mitigate such attacks. In particular, reception of a packet with no correct HMAC creates no local state whatsoever (Section 4.3). Reception of a replayed packet with 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 - information to validate the challenge reply. However, the nonce - included in a challenge request and echoed in the challenge reply can - be fairly large (up to 192 octets), which should in principle permit + Receiving a replayed packet with an obsolete index causes an entry to + be created in the Neighbour Table, which, at first sight, makes the + protocol susceptible to resource exhaustion attacks (similarly to the + 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 nonce itself. 7. IANA Considerations IANA has allocated the following values in the Babel TLV Types registry: +------+-------------------+---------------+ | Type | Name | Reference | @@ -750,27 +771,31 @@ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. 9.2. Informational References [I-D.ietf-babel-dtls] Decimo, A., Schinazi, D., and J. Chroboczek, "Babel 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, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . + [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common + Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, + . + [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, . [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication", RFC 7298, DOI 10.17487/RFC7298, July 2014, . @@ -851,20 +876,31 @@ 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 Allow discarding challenge requests when they carry an old PC. B.7. Changes since draft-ietf-babel-hmac-06 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 Clara Do IRIF, University of Paris-Diderot 75205 Paris Cedex 13 France Email: clarado_perso@yahoo.fr Weronika Kolodziejak