idnits 2.17.1 draft-chroboczek-babel-security-considerations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' Security considerations for the Babel routing protocol' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 7, 2015) is 3308 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-chroboczek-babel-diversity-routing-00 ** Obsolete normative reference: RFC 6126 (Obsoleted by RFC 8966) ** Obsolete normative reference: RFC 7298 (Obsoleted by RFC 8967) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Chroboczek 3 Internet-Draft PPS, University of Paris-Diderot 4 Intended status: Informational April 7, 2015 5 Expires: October 9, 2015 7 Security considerations for the Babel routing protocol 8 draft-chroboczek-babel-security-considerations-00 10 Abstract 12 Where we stress that the Babel routing protocol is completely 13 insecure. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on October 9, 2015. 32 Copyright Notice 34 Copyright (c) 2015 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Active attacks . . . . . . . . . . . . . . . . . . . . . . . 3 51 2.1. Routing table poisoning . . . . . . . . . . . . . . . . . 3 52 2.2. Amplification due to requests . . . . . . . . . . . . . . 4 53 2.3. Covert channel . . . . . . . . . . . . . . . . . . . . . 4 54 2.4. Mitigations and solutions . . . . . . . . . . . . . . . . 4 55 3. Passive attacks . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.1. Stable node identifiers . . . . . . . . . . . . . . . . . 5 57 3.2. Mitigations and solutions . . . . . . . . . . . . . . . . 5 58 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 62 1. Introduction 64 The Babel routing protocol [RFC6126] is a lightweight and robust 65 routing protocol that aims at being applicable in a wide range of 66 situations where familiar link-state routing protocols perform 67 suboptimally, ranging from lossy and unstable radio networks through 68 overlay networks and hybdrid networks (networks consisting of 69 technologies with widely different performance characteristics). 71 Because of the wide applicability of Babel, no single security 72 technology is likely to be acceptable to all the users of Babel. In 73 particular, while symmetric cryptographic authentication technologies 74 (such as the one described in [RFC7298]) solve many of the security 75 issues of Babel in the vast majority of deployments, there may be 76 applications of Babel where they are not applicable, either because 77 their functionality is insufficient (e.g. no support for asymmetric 78 cryptography) or because of implementation cost (not only CPU cost). 80 For that reason, RFC 6126 does not specify any particular "must 81 implement" technology, and honestly mentions that "As defined in this 82 document, Babel is a completely insecure protocol" (Section 6 of 83 [RFC6126]). We would be opposed to defining a single "must 84 implement" security mechanism, or including such a mechanism in the 85 base Babel specification, at least until there is enough 86 implementation and deployment experience to allow us to say "this is 87 the right security mechanism for Babel". 89 Our position is consistent with the letter and the spirit of [BCP61]. 90 BCP 61 stresses that security is necessary, but it does not specify 91 how security is to be achieved. It does not mandate that a protocol 92 should have a single "must implement" security mechanism, nor does it 93 require that it should be included in the base specification. 95 In this document, we describe some of the attacks that are easily 96 performed against an unsecured Babel router, and describe the 97 mitigations and solutions known to us. 99 2. Active attacks 101 In this section, we describe some active attacks -- attacks that can 102 be performed by an attacker that is able and willing to send Babel 103 control traffic to Babel nodes. 105 2.1. Routing table poisoning 107 An attacker that is able to send packets containing Update TLVs can 108 insert hostile entries into the victim's routing table. A routing 109 table that contains such hostile routes is said to be poisoned. 111 2.1.1. Lower metric attack 113 An attacker that is in a sufficiently central position in a Babel 114 routing domain can announce hostile routes that carry a lower metric 115 than the authentic routes. Babel's route selection mechanism will 116 prefer these routes to the legitimate but higher-metric routes, and 117 therefore poison its routing table. 119 2.1.2. Higher seqno attack 121 An attacker that is unable to achieve a sufficiently low metric 122 (presumably because it cannot reach a sufficiently central position 123 in a Babel routing domain) can still poison routing tables by 124 announcing a seqno that is higher than the seqno of the legitimate 125 routes. While Babel's route selection algorithm will normally ignore 126 higher-metric routes, a victim that is suffering temporary starvation 127 (Section 2.5 of [RFC6126]) will, under some circumstances, 128 temporarily switch to a higher-seqno route and therefore poison its 129 routing table. 131 2.1.3. Replay attack 133 Even if Babel packets are authenticated, in the presence of static 134 keying an attacker may capture enough authentified low-metric updates 135 to perform routing table poisoning. The seqno mechanism does not do 136 anything to protect against this attack, as Babel nodes do not ignore 137 routes with an unexpected seqno; in any case, the seqno space is 138 circular, and seqnos are reused after a few hours or at most days. 140 2.1.4. Amplification through routing table poisoning 142 An attacker that is able to perform routing table poisoning may 143 announce a third party next hop (Section 4.4.8 of [RFC6126]), and 144 therefore redirect a node's data traffic to a third party, which will 145 potentially suffer a denial of service. 147 2.2. Amplification due to requests 149 The Babel protocol includes the ability to request a full routing 150 table update by sending a "wildcard request". Wildcard request may 151 be sent over multicast, and in a dense network a single request TLV 152 may cause a significant amount of traffic, thus potentially 153 performing a denial of service. 155 2.3. Covert channel 157 Babel is an extensible protocol. Babel's extension mechanism 158 [BABEL-EXT] allows attaching extension data to almost any TLV in a 159 Babel packet; this data will be silently ignored by an implementation 160 that doesn't understand the extension, and can therefore be used as a 161 covert channel that is propagated for just one hop. 163 Another approach consists in encoding covert information within one 164 of the currently defined extensions, for example in the radio 165 interference information carried by [BABEL-Z]. The advantage of this 166 method is that the information will be propagated across the Babel 167 routing domain by non-collaborating routers. 169 2.4. Mitigations and solutions 171 Some of the attacks in this section are avoided by using a 172 cryptographic authentication mechanism with replay protection, such 173 as the one defined in [RFC7298]. However, in some deployments such 174 mechanisms may not be desirable, either due to implementation 175 complexity or to the difficulty of deploying symmetric keys. 177 If the Babel traffic is protected by some lower-layer mechanism, the 178 replay attack described in Section 2.1.3 above can be avoided by 179 using a replay protection mechanism, such as the one described in 180 Section 5.1 of [RFC7298], and which is independent of the rest of the 181 protocol described in that document. 183 If Babel traffic is carried over IPv6, which is normally the case, 184 Babel packets are sent from a link-local address. Since Babel nodes 185 discard Babel packets that are not sent from a link-local address 186 (Section 4 of [RFC6126]), and since link-local packets are unable to 187 cross routers, this prevents all of the attacks in this section 188 unless an attacker is able to send traffic from a link directly 189 attached to a Babel node. 191 No such natural protection is available when Babel traffic is carried 192 over IPv4, which does not have an equivalent to IPv6 link-local 193 addresses. However, no implementation of Babel known to us carries 194 its control traffic over IPv4. 196 We are not aware of any solution or mitigation technique to the 197 covert channel problem. As far as we can tell, there is nothing that 198 can be done to protect against a covert channel if untrusted routers 199 are allowed to join the routing domain. 201 3. Passive attacks 203 In this section, we describe some attacks that can be performed by an 204 attacker that is unable or unwilling to send Babel protocol packets, 205 but that is able to eavesdrop on a link that carries Babel control 206 traffic. 208 3.1. Stable node identifiers 210 There are three ways in which Babel traffic can be used to identify a 211 node. Babel Hello TLVs carry a unique (within the routing domain) 212 64 bit identifier, known as the "router-id"; Section 3 of [RFC6126] 213 recommends that router-ids be allocated in modified EUI-64 format 214 [RFC4291], presumably from a hardware address. Router-ids can 215 therefore serve as a stable node identifier. 217 In addition, when Babel control traffic is carried over IPv6, it is 218 sent from a link-local IPv6 address. Such addresses are usually 219 generated from a hardware address, and can therefore be used as a 220 stable node identifier. 222 Finally, Babel Update TLVs carry the set of prefixes announced by a 223 node. The prefixes announced with a metric of 0 are prefixes of 224 directly connected networks, which in some topologies can be used as 225 a stable node identifier. 227 3.2. Mitigations and solutions 229 The stable identifier nature of a router-id can be mitigated by 230 choosing router-ids randomly, and changing them periodically. 231 However, the protocol does not allow changing router-ids gracefully: 232 a Babel node that changes router-ids must tear down all of its 233 neighbour associations. Current implementations are only able to 234 change router-id at startup. 236 The same approach, with the same caveats, can be taken to change 237 link-local interface addresses. 239 Whether the same approach can be used to rotate locally redistributed 240 prefixes depends on the topology and the way the network is managed. 241 At any rate, the Babel protocol allows rotating announced addresses 242 in a graceful manner. 244 4. Conclusion 246 The Babel routing protocol, as defined in [RFC6126], is a completely 247 insecure protocol. Due to the wide applicability of Babel, no single 248 security mechanism is likely to satisfy all the needs of Babel's 249 userbase, and hence no "must implement" security mechanism should be 250 defined for Babel. 252 Implementors and users must be aware of this fact, and use security 253 mechanisms or mitigation techniques that are adapted to the nature of 254 their deployment. One such security mechanism can be readily 255 integrated to the protocol [RFC7298] (sample code is available); 256 alternatively, a lower-layer mechanism that is not vulnerable to 257 replay attacks may be used. 259 5. References 261 [BABEL-EXT] 262 Chroboczek, J., "Extension Mechanism for the Babel Routing 263 Protocol", draft-chroboczek-babel-extension-mechanism-04 264 (work in progress), March 2015. 266 [BABEL-Z] Chroboczek, J., "Diversity Routing for the Babel Routing 267 Protocol", draft-chroboczek-babel-diversity-routing-00 268 (work in progress), July 2014. 270 [BCP61] Schiller, J., "Strong Security Requirements for Internet 271 Engineering Task Force Standard Protocols", BCP 61, RFC 272 3365, August 2002. 274 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 275 Architecture", RFC 4291, February 2006. 277 [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, 278 February 2011. 280 [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code 281 (HMAC) Cryptographic Authentication", RFC 7298, July 2014. 283 Author's Address 285 Juliusz Chroboczek 286 PPS, University of Paris-Diderot 287 Case 7014 288 75205 Paris Cedex 13 289 France 291 Email: jch@pps.univ-paris-diderot.fr