Network Working Group J. Chroboczek Internet-Draft PPS, University of Paris-Diderot Intended status: Informational April 7, 2015 Expires: October 9, 2015 Security considerations for the Babel routing protocol draft-chroboczek-babel-security-considerations-00 Abstract Where we stress that the Babel routing protocol is completely insecure. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 http://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 October 9, 2015. Copyright Notice Copyright (c) 2015 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Chroboczek Expires October 9, 2015 [Page 1] Internet-Draft Babel security considerations April 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Active attacks . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Routing table poisoning . . . . . . . . . . . . . . . . . 3 2.2. Amplification due to requests . . . . . . . . . . . . . . 4 2.3. Covert channel . . . . . . . . . . . . . . . . . . . . . 4 2.4. Mitigations and solutions . . . . . . . . . . . . . . . . 4 3. Passive attacks . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Stable node identifiers . . . . . . . . . . . . . . . . . 5 3.2. Mitigations and solutions . . . . . . . . . . . . . . . . 5 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction The Babel routing protocol [RFC6126] is a lightweight and robust routing protocol that aims at being applicable in a wide range of situations where familiar link-state routing protocols perform suboptimally, ranging from lossy and unstable radio networks through overlay networks and hybdrid networks (networks consisting of technologies with widely different performance characteristics). Because of the wide applicability of Babel, no single security technology is likely to be acceptable to all the users of Babel. In particular, while symmetric cryptographic authentication technologies (such as the one described in [RFC7298]) solve many of the security issues of Babel in the vast majority of deployments, there may be applications of Babel where they are not applicable, either because their functionality is insufficient (e.g. no support for asymmetric cryptography) or because of implementation cost (not only CPU cost). For that reason, RFC 6126 does not specify any particular "must implement" technology, and honestly mentions that "As defined in this document, Babel is a completely insecure protocol" (Section 6 of [RFC6126]). We would be opposed to defining a single "must implement" security mechanism, or including such a mechanism in the base Babel specification, at least until there is enough implementation and deployment experience to allow us to say "this is the right security mechanism for Babel". Our position is consistent with the letter and the spirit of [BCP61]. BCP 61 stresses that security is necessary, but it does not specify how security is to be achieved. It does not mandate that a protocol should have a single "must implement" security mechanism, nor does it require that it should be included in the base specification. Chroboczek Expires October 9, 2015 [Page 2] Internet-Draft Babel security considerations April 2015 In this document, we describe some of the attacks that are easily performed against an unsecured Babel router, and describe the mitigations and solutions known to us. 2. Active attacks In this section, we describe some active attacks -- attacks that can be performed by an attacker that is able and willing to send Babel control traffic to Babel nodes. 2.1. Routing table poisoning An attacker that is able to send packets containing Update TLVs can insert hostile entries into the victim's routing table. A routing table that contains such hostile routes is said to be poisoned. 2.1.1. Lower metric attack An attacker that is in a sufficiently central position in a Babel routing domain can announce hostile routes that carry a lower metric than the authentic routes. Babel's route selection mechanism will prefer these routes to the legitimate but higher-metric routes, and therefore poison its routing table. 2.1.2. Higher seqno attack An attacker that is unable to achieve a sufficiently low metric (presumably because it cannot reach a sufficiently central position in a Babel routing domain) can still poison routing tables by announcing a seqno that is higher than the seqno of the legitimate routes. While Babel's route selection algorithm will normally ignore higher-metric routes, a victim that is suffering temporary starvation (Section 2.5 of [RFC6126]) will, under some circumstances, temporarily switch to a higher-seqno route and therefore poison its routing table. 2.1.3. Replay attack Even if Babel packets are authenticated, in the presence of static keying an attacker may capture enough authentified low-metric updates to perform routing table poisoning. The seqno mechanism does not do anything to protect against this attack, as Babel nodes do not ignore routes with an unexpected seqno; in any case, the seqno space is circular, and seqnos are reused after a few hours or at most days. Chroboczek Expires October 9, 2015 [Page 3] Internet-Draft Babel security considerations April 2015 2.1.4. Amplification through routing table poisoning An attacker that is able to perform routing table poisoning may announce a third party next hop (Section 4.4.8 of [RFC6126]), and therefore redirect a node's data traffic to a third party, which will potentially suffer a denial of service. 2.2. Amplification due to requests The Babel protocol includes the ability to request a full routing table update by sending a "wildcard request". Wildcard request may be sent over multicast, and in a dense network a single request TLV may cause a significant amount of traffic, thus potentially performing a denial of service. 2.3. Covert channel Babel is an extensible protocol. Babel's extension mechanism [BABEL-EXT] allows attaching extension data to almost any TLV in a Babel packet; this data will be silently ignored by an implementation that doesn't understand the extension, and can therefore be used as a covert channel that is propagated for just one hop. Another approach consists in encoding covert information within one of the currently defined extensions, for example in the radio interference information carried by [BABEL-Z]. The advantage of this method is that the information will be propagated across the Babel routing domain by non-collaborating routers. 2.4. Mitigations and solutions Some of the attacks in this section are avoided by using a cryptographic authentication mechanism with replay protection, such as the one defined in [RFC7298]. However, in some deployments such mechanisms may not be desirable, either due to implementation complexity or to the difficulty of deploying symmetric keys. If the Babel traffic is protected by some lower-layer mechanism, the replay attack described in Section 2.1.3 above can be avoided by using a replay protection mechanism, such as the one described in Section 5.1 of [RFC7298], and which is independent of the rest of the protocol described in that document. If Babel traffic is carried over IPv6, which is normally the case, Babel packets are sent from a link-local address. Since Babel nodes discard Babel packets that are not sent from a link-local address (Section 4 of [RFC6126]), and since link-local packets are unable to cross routers, this prevents all of the attacks in this section Chroboczek Expires October 9, 2015 [Page 4] Internet-Draft Babel security considerations April 2015 unless an attacker is able to send traffic from a link directly attached to a Babel node. No such natural protection is available when Babel traffic is carried over IPv4, which does not have an equivalent to IPv6 link-local addresses. However, no implementation of Babel known to us carries its control traffic over IPv4. We are not aware of any solution or mitigation technique to the covert channel problem. As far as we can tell, there is nothing that can be done to protect against a covert channel if untrusted routers are allowed to join the routing domain. 3. Passive attacks In this section, we describe some attacks that can be performed by an attacker that is unable or unwilling to send Babel protocol packets, but that is able to eavesdrop on a link that carries Babel control traffic. 3.1. Stable node identifiers There are three ways in which Babel traffic can be used to identify a node. Babel Hello TLVs carry a unique (within the routing domain) 64 bit identifier, known as the "router-id"; Section 3 of [RFC6126] recommends that router-ids be allocated in modified EUI-64 format [RFC4291], presumably from a hardware address. Router-ids can therefore serve as a stable node identifier. In addition, when Babel control traffic is carried over IPv6, it is sent from a link-local IPv6 address. Such addresses are usually generated from a hardware address, and can therefore be used as a stable node identifier. Finally, Babel Update TLVs carry the set of prefixes announced by a node. The prefixes announced with a metric of 0 are prefixes of directly connected networks, which in some topologies can be used as a stable node identifier. 3.2. Mitigations and solutions The stable identifier nature of a router-id can be mitigated by choosing router-ids randomly, and changing them periodically. However, the protocol does not allow changing router-ids gracefully: a Babel node that changes router-ids must tear down all of its neighbour associations. Current implementations are only able to change router-id at startup. Chroboczek Expires October 9, 2015 [Page 5] Internet-Draft Babel security considerations April 2015 The same approach, with the same caveats, can be taken to change link-local interface addresses. Whether the same approach can be used to rotate locally redistributed prefixes depends on the topology and the way the network is managed. At any rate, the Babel protocol allows rotating announced addresses in a graceful manner. 4. Conclusion The Babel routing protocol, as defined in [RFC6126], is a completely insecure protocol. Due to the wide applicability of Babel, no single security mechanism is likely to satisfy all the needs of Babel's userbase, and hence no "must implement" security mechanism should be defined for Babel. Implementors and users must be aware of this fact, and use security mechanisms or mitigation techniques that are adapted to the nature of their deployment. One such security mechanism can be readily integrated to the protocol [RFC7298] (sample code is available); alternatively, a lower-layer mechanism that is not vulnerable to replay attacks may be used. 5. References [BABEL-EXT] Chroboczek, J., "Extension Mechanism for the Babel Routing Protocol", draft-chroboczek-babel-extension-mechanism-04 (work in progress), March 2015. [BABEL-Z] Chroboczek, J., "Diversity Routing for the Babel Routing Protocol", draft-chroboczek-babel-diversity-routing-00 (work in progress), July 2014. [BCP61] Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", BCP 61, RFC 3365, August 2002. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, February 2011. [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication", RFC 7298, July 2014. Chroboczek Expires October 9, 2015 [Page 6] Internet-Draft Babel security considerations April 2015 Author's Address Juliusz Chroboczek PPS, University of Paris-Diderot Case 7014 75205 Paris Cedex 13 France Email: jch@pps.univ-paris-diderot.fr Chroboczek Expires October 9, 2015 [Page 7]