idnits 2.17.1 draft-ietf-babel-dtls-09.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 13, 2019) is 1718 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7525 (ref. 'BCP195') (Obsoleted by RFC 9325) == Outdated reference: A later version (-20) exists of draft-ietf-babel-rfc6126bis-13 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-12) exists of draft-ietf-babel-hmac-09 == Outdated reference: A later version (-13) exists of draft-ietf-tls-dtls-connection-id-06 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Decimo 3 Internet-Draft IRIF, University of Paris-Diderot 4 Intended status: Standards Track D. Schinazi 5 Expires: February 14, 2020 Google LLC 6 J. Chroboczek 7 IRIF, University of Paris-Diderot 8 August 13, 2019 10 Babel Routing Protocol over Datagram Transport Layer Security 11 draft-ietf-babel-dtls-09 13 Abstract 15 The Babel Routing Protocol does not contain any means to authenticate 16 neighbours or provide integrity or confidentiality for messages sent 17 between them. This document specifies a mechanism to ensure these 18 properties, using Datagram Transport Layer Security (DTLS). 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on February 14, 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Specification of Requirements . . . . . . . . . . . . . . 2 56 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Operation of the Protocol . . . . . . . . . . . . . . . . . . 3 58 2.1. DTLS Connection Initiation . . . . . . . . . . . . . . . 3 59 2.2. Protocol Encoding . . . . . . . . . . . . . . . . . . . . 4 60 2.3. Transmission . . . . . . . . . . . . . . . . . . . . . . 4 61 2.4. Reception . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.5. Neighbour table entry . . . . . . . . . . . . . . . . . . 5 63 2.6. Simultaneous operation of both Babel over DTLS and 64 unprotected Babel on a Node . . . . . . . . . . . . . . . 6 65 2.7. Simultaneous operation of both Babel over DTLS and 66 unprotected Babel on a Network . . . . . . . . . . . . . 6 67 3. Interface Maximum Transmission Unit Issues . . . . . . . . . 6 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 72 6.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Appendix A. Performance Considerations . . . . . . . . . . . . . 9 74 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 The Babel Routing Protocol [RFC6126bis] does not contain any means to 80 authenticate neighbours or protect messages sent between them. 81 Because of this, an attacker is able to send maliciously crafted 82 Babel messages which could lead a network to route traffic to an 83 attacker or to an under-resourced target causing denial of service. 84 This document specifies a mechanism to prevent such attacks, using 85 Datagram Transport Layer Security (DTLS) [RFC6347]. 87 1.1. Specification of Requirements 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 91 "OPTIONAL" in this document are to be interpreted as described in BCP 92 14 [RFC2119] [RFC8174] when, and only when, they appear in all 93 capitals, as shown here. 95 1.2. Applicability 97 The protocol described in this document protects Babel packets with 98 DTLS. As such, it inherits the features offered by DTLS, notably 99 authentication, integrity, optional replay protection, 100 confidentiality and asymmetric keying. It is therefore expected to 101 be applicable in a wide range of environments. 103 There exists another mechanism for securing Babel, namely Babel HMAC 104 authentication [BABEL-HMAC]. HMAC only offers basic features, namely 105 authentication, integrity and replay protection with a small number 106 of symmetric keys. A comparison of Babel security mechanisms and 107 their applicability can be found in [RFC6126bis]. 109 Note that Babel over DTLS provides a single authentication domain, 110 meaning that all nodes that have the right credentials can convey any 111 and all routing information. 113 DTLS supports several mechanisms by which nodes can identify 114 themselves and prove possession of secrets tied to these identities. 115 This document does not prescribe which of these mechanisms to use; 116 details of identity management are left to deployment profiles of 117 Babel over DTLS. 119 2. Operation of the Protocol 121 Babel over DTLS requires some changes to how Babel operates. First, 122 DTLS is a client-server protocol, while Babel is a peer-to-peer 123 protocol. Second, DTLS can only protect unicast communication, while 124 Babel packets can be sent over to both unicast and multicast 125 destinations. 127 2.1. DTLS Connection Initiation 129 Babel over DTLS operates on a different port than unencrypted Babel. 130 All Babel over DTLS nodes MUST act as DTLS servers on a given UDP 131 port, and MUST listen for unencrypted Babel traffic on another UDP 132 port, which MUST be distinct from the first one. The default port 133 for Babel over DTLS is registered with IANA as the "babel-dtls" port 134 (UDP port TBD, see Section 4), and the port exchanging unencrypted 135 Babel traffic is registered as the "babel" port (UDP port 6696, see 136 Section 5 of [RFC6126bis]). 138 When a Babel node discovers a new neighbour (generally by receiving 139 an unencrypted multicast Babel packet), it compares the neighbour's 140 IP address with its own, using network byte ordering. If a node's 141 address is lower than the recently discovered neighbour's address, it 142 acts as a client and connects to the neighbour. In other words, the 143 node with the lowest address is the DTLS client for this pairwise 144 relationship. As an example, fe80::1:2 is considered lower than 145 fe80::2:1. 147 The node acting as DTLS client initiates its DTLS connection from an 148 ephemeral UDP port. Nodes SHOULD ensure that new client DTLS 149 connections use different ephemeral ports from recently used 150 connections to allow servers to differentiate between the new and old 151 DTLS connections. Alternatively, nodes could use DTLS connection 152 identifiers [DTLS-CID] as a higher-entropy mechanism to distinguish 153 between connections. 155 When a node receives a new DTLS connection, it MUST verify that the 156 source IP address is either an IPv6 link-local address or an IPv4 157 address belonging to the local network; if it is neither, it MUST 158 reject the connection. Nodes use mutual authentication 159 (authenticating both client and server); clients MUST authenticate 160 servers and servers MUST authenticate clients. Implementations MUST 161 support authenticating peers against a local store of credentials. 162 If either node fails to authenticate its peer against its local 163 policy, it MUST abort the DTLS handshake. The guidance given in 164 [BCP195] MUST be followed to avoid attacks on DTLS. Additionally, 165 nodes MUST only negotiate DTLS version 1.2 or higher. Nodes MUST use 166 DTLS replay protection to prevent attackers from replaying stale 167 information. Nodes SHOULD drop packets that have been reordered by 168 more than two IHU (I Heard You) intervals, to avoid letting attackers 169 make stale information last longer. If a node receives a new DTLS 170 connection from a neighbour to whom it already has a connection, the 171 node MUST NOT discard the older connection until it has completed the 172 handshake of the new one and validated the identity of the peer. 174 2.2. Protocol Encoding 176 Babel over DTLS sends all unicast Babel packets protected by DTLS. 177 The entire Babel packet, from the Magic byte at the start of the 178 Babel header to the last byte of the Babel packet trailer, is sent 179 protected by DTLS. 181 2.3. Transmission 183 When sending packets, Babel over DTLS nodes MUST NOT send any TLVs 184 over the unprotected "babel" port, with the exception of Hello TLVs 185 without the Unicast flag set. Babel over DTLS nodes MUST NOT send 186 any unprotected unicast packets. This ensures the confidentiality of 187 the information sent in Babel packets (e.g., the network topology) by 188 only sending it encrypted by DTLS. Unless some out-of-band neighbour 189 discovery mechanism is available, nodes SHOULD periodically send 190 unprotected multicast Hellos to ensure discovery of new neighbours. 192 In order to maintain bidirectional reachability, nodes can either 193 rely entirely on unprotected multicast Hellos, or send protected 194 unicast Hellos in addition to the multicast Hellos. 196 Since Babel over DTLS only protects unicast packets, implementors may 197 implement Babel over DTLS by modifying an implementation of Babel 198 without DTLS support, and replacing any TLV previously sent over 199 multicast with a separate TLV sent over unicast for each neighbour. 200 TLVs previously sent over multicast can be replaced with the same 201 contents over unicast, with the exception of Hellos as described 202 above. Some implementations could also change the contents of IHU 203 TLVs when converting to unicast in order to remove redundant 204 information. 206 2.4. Reception 208 Babel over DTLS nodes can receive Babel packets either protected over 209 a DTLS connection, or unprotected directly over the "babel" port. To 210 ensure the security properties of this mechanism, unprotected packets 211 are treated differently. Nodes MUST silently ignore any unprotected 212 packet sent over unicast. When parsing an unprotected packet, a node 213 MUST silently ignore all TLVs that are not of type Hello. Nodes MUST 214 also silently ignore any unprotected Hello with the Unicast flag set. 215 Note that receiving an unprotected packet can still be used to 216 discover new neighbours, even when all TLVs in that packet are 217 silently ignored. 219 2.5. Neighbour table entry 221 It is RECOMMENDED for nodes to associate the state of their DTLS 222 connection with their neighbour table. When a neighbour entry is 223 flushed from the neighbour table (Appendix A of [RFC6126bis]), its 224 associated DTLS state SHOULD be discarded. The node SHOULD send a 225 DTLS close_notify alert to the neighbour if it believes the link is 226 still viable. 228 While DTLS provides protection against an attacker that replays valid 229 packets, DTLS is not able to detect when an active on-path attacker 230 intercepts valid packets and resends them at a later time. This 231 attack could be used to make a node believe it has bidirectional 232 reachability to a neighbour even though that neighbour has 233 disconnected from the network. To prevent this attack, nodes MUST 234 discard the DTLS state associated with a neighbour after a finite 235 time of not receiving valid DTLS packets. This can be implemented 236 by, for example, discarding a neighbour's DTLS state when its 237 associated IHU timer fires. Note that relying solely on the receipt 238 of Hellos is not sufficient as multicast Hellos are sent unprotected. 239 Additionally, an attacker could save some packets and replay them 240 later in hopes of propagating stale routing information at a later 241 time. To mitigate this, nodes MUST discard received packets that 242 have been reordered by more than one IHU interval. 244 2.6. Simultaneous operation of both Babel over DTLS and unprotected 245 Babel on a Node 247 Implementations MAY implement both Babel over DTLS and unprotected 248 Babel. Additionally, a node MAY simultaneously run both Babel over 249 DTLS and unprotected Babel. However, a node running both MUST ensure 250 that it runs them on separate interfaces, as the security properties 251 of Babel over DTLS rely on not accepting unprotected Babel packets 252 (other than multicast Hellos). A node MAY allow configuration 253 options to allow unprotected Babel on some interfaces but not others; 254 this effectively gives nodes on that interface the same access as 255 authenticated nodes, and SHOULD NOT be done unless that interface has 256 a mechanism to authenticate nodes at a lower layer (e.g., IPsec). 258 2.7. Simultaneous operation of both Babel over DTLS and unprotected 259 Babel on a Network 261 If Babel over DTLS and unprotected Babel are both operated on the 262 same network, the Babel over DTLS implementation will receive 263 unprotected multicast Hellos and attempt to initiate a DTLS 264 connection. These connection attempts can be sent to nodes that only 265 run unprotected Babel, who will not respond. Babel over DTLS 266 implementations SHOULD therefore rate-limit their DTLS connection 267 attempts to avoid causing undue load on the network. 269 3. Interface Maximum Transmission Unit Issues 271 Compared to unprotected Babel, DTLS adds header, authentication tag 272 and possibly block-size padding overhead to every packet. This 273 reduces the size of the Babel payload that can be carried. This 274 document does not relax the packet size requirements in Section 4 of 275 [RFC6126bis], but recommends that DTLS overhead be taken into account 276 when computing maximum packet size. 278 More precisely, nodes SHOULD compute the overhead of DTLS depending 279 on the ciphersuites in use, and SHOULD NOT send Babel packets larger 280 than the interface maximum transmission unit (MTU) minus the overhead 281 of IP, UDP and DTLS. Nodes MUST NOT send Babel packets larger than 282 the attached interface's MTU adjusted for known lower-layer headers 283 (at least UDP and IP) or 512 octets, whichever is larger, but not 284 exceeding 2^16 - 1 adjusted for lower-layer headers. Every Babel 285 speaker MUST be able to receive packets that are as large as any 286 attached interface's MTU adjusted for UDP and IP headers or 512 287 octets, whichever is larger. Note that this requirement on reception 288 does not take into account the overhead of DTLS because the peer may 289 not have the ability to compute the overhead of DTLS and the packet 290 may be fragmented by lower layers. 292 Note that distinct DTLS connections can use different ciphers, which 293 can have different amounts of per-packet overhead. Therefore, the 294 MTU to one neighbour can be different from the MTU to another 295 neighbour on the same link. 297 4. IANA Considerations 299 If this document is approved, IANA is requested to register a UDP 300 port number, called "babel-dtls", for use by Babel over DTLS. 301 Details of the request to IANA are as follows: 303 o Assignee: IESG, iesg@ietf.org 305 o Contact Person: IETF Chair, chair@ietf.org 307 o Transport Protocols: UDP only 309 o Service Code: None 311 o Service Name: babel-dtls 313 o Desired Port Number: 6699 315 o Description: Babel Routing Protocol over DTLS 317 o Reference: This document 319 o Defined TXT Keys: None 321 5. Security Considerations 323 A malicious client might attempt to perform a high number of DTLS 324 handshakes with a server. As the clients are not uniquely identified 325 by the protocol until the handshake completes and can be obfuscated 326 with IPv6 temporary addresses, a server needs to mitigate the impact 327 of such an attack. Note that attackers might attempt to keep in- 328 progress handshakes open for as long as possible by using variants on 329 the attack commonly known as Slowloris [SLOWLORIS]. Mitigating these 330 attacks might involve rate limiting handshakes from a given subnet or 331 more advanced denial of service avoidance techniques beyond the scope 332 of this document. 334 Babel over DTLS allows sending multicast Hellos unprotected; 335 attackers can therefore tamper with them. For example, an attacker 336 could send erroneous values for the Seqno and Interval fields, 337 causing bidirectional reachability detection to fail. While 338 implementations MAY use multicast Hellos for link quality estimation, 339 they SHOULD also emit protected unicast Hellos to prevent this class 340 of denial-of-service attack. 342 6. References 344 6.1. Normative References 346 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, 347 "Recommendations for Secure Use of Transport Layer 348 Security (TLS) and Datagram Transport Layer Security 349 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 350 2015, . 352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", BCP 14, RFC 2119, 354 DOI 10.17487/RFC2119, March 1997, 355 . 357 [RFC6126bis] 358 Chroboczek, J. and D. Schinazi, "The Babel Routing 359 Protocol", Internet Draft draft-ietf-babel-rfc6126bis-13, 360 August 2019. 362 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 363 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 364 January 2012, . 366 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 367 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 368 May 2017, . 370 6.2. Informative References 372 [BABEL-HMAC] 373 Do, C., Kolodziejak, W., and J. Chroboczek, "Babel 374 Cryptographic Authentication", Internet Draft draft-ietf- 375 babel-hmac-09, August 2019. 377 [DTLS-CID] 378 Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom, 379 "Connection Identifiers for DTLS 1.2", Internet Draft 380 draft-ietf-tls-dtls-connection-id-06, July 2019. 382 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 383 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 384 Transport Layer Security (TLS) and Datagram Transport 385 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 386 June 2014, . 388 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 389 Layer Security (TLS) False Start", RFC 7918, 390 DOI 10.17487/RFC7918, August 2016, 391 . 393 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 394 (TLS) Cached Information Extension", RFC 7924, 395 DOI 10.17487/RFC7924, July 2016, 396 . 398 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 399 Transport Layer Security (DTLS)", RFC 8094, 400 DOI 10.17487/RFC8094, February 2017, 401 . 403 [SLOWLORIS] 404 Hansen, R., "Welcome to Slowloris...", June 2009, 405 . 408 Appendix A. Performance Considerations 410 To reduce the number of octets taken by the DTLS handshake, 411 especially the size of the certificate in the ServerHello (which can 412 be several kilobytes), Babel peers can use raw public keys [RFC7250] 413 or the Cached Information Extension [RFC7924]. The Cached 414 Information Extension avoids transmitting the server's certificate 415 and certificate chain if the client has cached that information from 416 a previous TLS handshake. TLS False Start [RFC7918] can reduce round 417 trips by allowing the TLS second flight of messages 418 (ChangeCipherSpec) to also contain the (encrypted) Babel packet. 420 Appendix B. Acknowledgments 422 The authors would like to thank Roman Danyliw, Donald Eastlake, 423 Thomas Fossati, Benjamin Kaduk, Gabriel Kerneis, Mirja Kuehlewind, 424 Antoni Przygienda, Henning Rogge, Dan Romascanu, Barbara Stark, 425 Markus Stenberg, Dave Taht, Martin Thomson, Sean Turner and Martin 426 Vigoureux for their input and contributions. The performance 427 considerations in this document were inspired from the ones for DNS 428 over DTLS [RFC8094]. 430 Authors' Addresses 432 Antonin Decimo 433 IRIF, University of Paris-Diderot 434 Paris 435 France 437 Email: antonin.decimo@gmail.com 439 David Schinazi 440 Google LLC 441 1600 Amphitheatre Parkway 442 Mountain View, California 94043 443 USA 445 Email: dschinazi.ietf@gmail.com 447 Juliusz Chroboczek 448 IRIF, University of Paris-Diderot 449 Case 7014 450 75205 Paris Cedex 13 451 France 453 Email: jch@irif.fr