idnits 2.17.1 draft-ietf-babel-dtls-07.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 (July 5, 2019) is 1749 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) == Outdated reference: A later version (-20) exists of draft-ietf-babel-rfc6126bis-11 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-12) exists of draft-ietf-babel-hmac-07 == Outdated reference: A later version (-13) exists of draft-ietf-tls-dtls-connection-id-05 -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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: January 6, 2020 Google LLC 6 J. Chroboczek 7 IRIF, University of Paris-Diderot 8 July 5, 2019 10 Babel Routing Protocol over Datagram Transport Layer Security 11 draft-ietf-babel-dtls-07 13 Abstract 15 The Babel Routing Protocol does not contain any means to authenticate 16 neighbours or protect messages sent between them. This document 17 specifies a mechanism to ensure these properties, using Datagram 18 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 January 6, 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 . . . . . . . . . . . . . . . . . . . . 5 65 3. Interface Maximum Transmission Unit Issues . . . . . . . . . 6 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 6.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Appendix A. Performance Considerations . . . . . . . . . . . . . 8 72 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 The Babel Routing Protocol [RFC6126bis] does not contain any means to 78 authenticate neighbours or protect messages sent between them. 79 Because of this, an attacker is able to send maliciously crafted 80 Babel messages which could lead a network to route traffic to an 81 attacker or to an under-resourced target causing denial of service. 82 This document specifies a mechanism to prevent such attacks, using 83 Datagram Transport Layer Security (DTLS) [RFC6347]. 85 1.1. Specification of Requirements 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 89 "OPTIONAL" in this document are to be interpreted as described in BCP 90 14 [RFC2119] [RFC8174] when, and only when, they appear in all 91 capitals, as shown here. 93 1.2. Applicability 95 The protocol described in this document protects Babel packets with 96 DTLS. As such, it inherits the features offered by DTLS, notably 97 authentication, integrity, replay protection, confidentiality and 98 asymmetric keying. It is therefore expected to be applicable in a 99 wide range of environments. 101 There exists another mechanism for securing Babel, namely Babel HMAC 102 authentication [BABEL-HMAC]. HMAC only offers basic features, namely 103 authentication, integrity and replay protection with a small number 104 of symmetric keys. A comparison of Babel security mechanisms and 105 their applicability can be found in [RFC6126bis]. 107 2. Operation of the Protocol 109 Babel over DTLS requires some changes to how Babel operates. First, 110 DTLS is a client-server protocol, while Babel is a peer-to-peer 111 protocol. Second, DTLS can only protect unicast communication, while 112 Babel packets can be sent over to both unicast and multicast 113 destinations. 115 2.1. DTLS Connection Initiation 117 Babel over DTLS operates on a different port than unencrypted Babel. 118 All Babel over DTLS nodes MUST act as DTLS servers on a given UDP 119 port, and MUST listen for unencrypted Babel traffic on another UDP 120 port, which MUST be distinct from the first one. The default port 121 for Babel over DTLS is registered with IANA as the "babel-dtls" port 122 (UDP port TBD, see Section 4), and the port exchanging unencrypted 123 Babel traffic is registered as the "babel" port (UDP port 6696, see 124 Section 5 of [RFC6126bis]). 126 When a Babel node discovers a new neighbour (generally by receiving 127 an unencrypted multicast Babel packet), it compares the neighbour's 128 IPv6 link-local address with its own, using network byte ordering. 129 If a node's address is lower than the recently discovered neighbour's 130 address, it acts as a client and connects to the neighbour. In other 131 words, the node with the lowest address is the DTLS client for this 132 pairwise relationship. As an example, fe80::1:2 is considered lower 133 than fe80::2:1. 135 The node acting as DTLS client initiates its DTLS connection from an 136 ephemeral UDP port. Nodes SHOULD ensure that new client DTLS 137 connections use different ephemeral ports from recently used 138 connections to allow servers to differentiate between the new and old 139 DTLS connections. Alternatively, nodes MAY use DTLS connection 140 identifiers [DTLS-CID] as a higher-entropy mechanism to distinguish 141 between connections. 143 When a node receives a new DTLS connection, it MUST verify that the 144 source IP address is an IPv6 link-local address; if it is not, it 145 MUST reject the connection. Nodes use mutual authentication 146 (authenticating both client and server); servers MUST send a 147 CertificateRequest message and subsequently authenticate the client. 148 Implementations MUST support authenticating peers against a local 149 store of credentials. If either node fails to authenticate its peer 150 against its local policy, it MUST abort the DTLS handshake. Nodes 151 MUST only negotiate DTLS version 1.2 or higher. Nodes MUST use DTLS 152 replay protection to prevent attackers from replaying stale 153 information. Nodes SHOULD drop packets that have been reordered by 154 more than two IHU intervals, to avoid letting attackers make stale 155 information last longer. If a node receives a new DTLS connection 156 from a neighbour to whom it already has a connection, the node MUST 157 NOT discard the older connection until it has completed the handshake 158 of the new one and validated the identity of the peer. 160 2.2. Protocol Encoding 162 Babel over DTLS sends all unicast Babel packets protected by DTLS. 163 The entire Babel packet, from the Magic byte at the start of the 164 Babel header to the last byte of the Babel packet trailer, is sent 165 protected by DTLS. 167 2.3. Transmission 169 When sending packets, Babel over DTLS nodes MUST NOT send any TLVs 170 over the unprotected "babel" port, with the exception of Hello TLVs 171 without the Unicast flag set. Babel over DTLS nodes MUST NOT send 172 any unprotected unicast packets. This ensures the confidentiality of 173 the information sent in Babel packets (e.g., the network topology) by 174 only sending it encrypted by DTLS. Unless some out-of-band neighbour 175 discovery mechanism is available, nodes SHOULD periodically send 176 unprotected multicast Hellos to ensure discovery of new neighbours. 177 In order to maintain bidirectional reachability, nodes can either 178 rely entirely on unprotected multicast Hellos, or send protected 179 unicast Hellos in addition to the multicast Hellos. 181 Since Babel over DTLS only protects unicast packets, implementors may 182 implement Babel over DTLS by modifying an implementation of Babel 183 without DTLS support, and replacing any TLV previously sent over 184 multicast with a separate TLV sent over unicast for each neighbour. 185 TLVs previously sent over multicast can be replaced with the same 186 contents over unicast, with the exception of Hellos as described 187 above. Some implementations could also change the contents of IHU 188 TLVs when converting to unicast in order to remove redundant 189 information. 191 2.4. Reception 193 Babel over DTLS nodes can receive Babel packets either protected over 194 a DTLS connection, or unprotected directly over the "babel" port. To 195 ensure the security properties of this mechanism, unprotected packets 196 are treated differently. Nodes MUST silently ignore any unprotected 197 packet sent over unicast. When parsing an unprotected packet, a node 198 MUST silently ignore all TLVs that are not of type Hello. Nodes MUST 199 also silently ignore any unprotected Hello with the Unicast flag set. 200 Note that receiving an unprotected packet can still be used to 201 discover new neighbours, even when all TLVs in that packet are 202 silently ignored. 204 2.5. Neighbour table entry 206 It is RECOMMENDED for nodes to associate the state of their DTLS 207 connection with their neighbour table. When a neighbour entry is 208 flushed from the neighbour table (Appendix A of [RFC6126bis]), its 209 associated DTLS state SHOULD be discarded. The node SHOULD send a 210 DTLS close_notify alert to the neighbour if it believes the link is 211 still viable. 213 While DTLS provides protection against an attacker that replays valid 214 packets, DTLS is not able to detect when an active on-path attacker 215 intercepts valid packets and resends them at a later time. This 216 attack could be used to make a node believe it has bidirectional 217 reachability to a neighbour even though that neighbour has 218 disconnected from the network. To prevent this attack, nodes MUST 219 discard the DTLS state associated with a neighbour after a finite 220 time of not receiving valid DTLS packets. This can be implemented 221 by, for example, discarding a neighbour's DTLS state when its 222 associated IHU timer fires. Note that relying solely on the receipt 223 of Hellos is not sufficient as multicast Hellos are sent unprotected. 225 2.6. Simultaneous operation of both Babel over DTLS and unprotected 226 Babel 228 Implementations MAY implement both Babel over DTLS and unprotected 229 Babel. However, accepting unprotected Babel packets (other than 230 multicast Hellos) loses the security properties of Babel over DTLS. 231 A node MAY allow configuration options to allow unprotected Babel on 232 some interfaces but not others; this effectively gives nodes on that 233 interface the same access as authenticated nodes, and SHOULD NOT be 234 done unless that interface has a mechanism to authenticate nodes at a 235 lower layer (e.g., IPsec). 237 3. Interface Maximum Transmission Unit Issues 239 Compared to unprotected Babel, DTLS adds header, authentication tag 240 and possibly block-size padding overhead to every packet. This 241 reduces the size of the Babel payload that can be carried. This 242 document does not relax the packet size requirements in Section 4 of 243 [RFC6126bis], but recommends that DTLS overhead be taken into account 244 when computing maximum packet size. 246 More precisely, nodes SHOULD compute the overhead of DTLS depending 247 on the ciphers in use, and SHOULD NOT send Babel packets larger than 248 the interface maximum transmission unit (MTU) minus the overhead of 249 IP, UDP and DTLS. Nodes MUST NOT send Babel packets larger than the 250 attached interface's MTU adjusted for known lower-layer headers (at 251 least UDP and IP) or 512 octets, whichever is larger, but not 252 exceeding 2^16 - 1 adjusted for lower-layer headers. Every Babel 253 speaker MUST be able to receive packets that are as large as any 254 attached interface's MTU adjusted for UDP and IP headers or 512 255 octets, whichever is larger. Note that this requirement on reception 256 does not take into account the overhead of DTLS because the peer may 257 not have the ability to compute the overhead of DTLS and the packet 258 may be fragmented by lower layers. 260 Note that distinct DTLS connections can use different ciphers, which 261 can have different amounts of overhead per packet. Therefore, the 262 MTU to one neighbour can be different from the MTU to another 263 neighbour on the same link. 265 4. IANA Considerations 267 If this document is approved, IANA is requested to register a UDP 268 port number, called "babel-dtls", for use by Babel over DTLS. 269 Details of the request to IANA are as follows: 271 o Assignee: IESG, iesg@ietf.org 273 o Contact Person: IETF Chair, chair@ietf.org 275 o Transport Protocols: UDP only 277 o Service Code: None 279 o Service Name: babel-dtls 281 o Desired Port Number: 6699 283 o Description: Babel Routing Protocol over DTLS 284 o Reference: This document 286 o Defined TXT Keys: None 288 5. Security Considerations 290 Confidential interaction between two Babel peers requires Datagram 291 Transport Layer Security (DTLS) with a cipher suite offering 292 confidentiality protection. The guidance given in [RFC7525] MUST be 293 followed to avoid attacks on DTLS. 295 A malicious client might attempt to perform a high number of DTLS 296 handshakes with a server. As the clients are not uniquely identified 297 by the protocol and can be obfuscated with IPv6 temporary addresses, 298 a server needs to mitigate the impact of such an attack. Such 299 mitigation might involve rate limiting handshakes from a given subnet 300 or more advanced denial of service avoidance techniques beyond the 301 scope of this document. 303 6. References 305 6.1. Normative References 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, 309 DOI 10.17487/RFC2119, March 1997, 310 . 312 [RFC6126bis] 313 Chroboczek, J. and D. Schinazi, "The Babel Routing 314 Protocol", Internet Draft draft-ietf-babel-rfc6126bis-11, 315 June 2019. 317 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 318 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 319 January 2012, . 321 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 322 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 323 May 2017, . 325 6.2. Informative References 327 [BABEL-HMAC] 328 Do, C., Kolodziejak, W., and J. Chroboczek, "Babel 329 Cryptographic Authentication", Internet Draft draft-ietf- 330 babel-hmac-07, June 2019. 332 [DTLS-CID] 333 Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom, 334 "Connection Identifiers for DTLS 1.2", Internet Draft 335 draft-ietf-tls-dtls-connection-id-05, October 2018. 337 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 338 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 339 Transport Layer Security (TLS) and Datagram Transport 340 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 341 June 2014, . 343 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 344 "Recommendations for Secure Use of Transport Layer 345 Security (TLS) and Datagram Transport Layer Security 346 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 347 2015, . 349 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 350 Layer Security (TLS) False Start", RFC 7918, 351 DOI 10.17487/RFC7918, August 2016, 352 . 354 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 355 (TLS) Cached Information Extension", RFC 7924, 356 DOI 10.17487/RFC7924, July 2016, 357 . 359 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 360 Transport Layer Security (DTLS)", RFC 8094, 361 DOI 10.17487/RFC8094, February 2017, 362 . 364 Appendix A. Performance Considerations 366 To reduce the number of octets taken by the DTLS handshake, 367 especially the size of the certificate in the ServerHello (which can 368 be several kilobytes), Babel peers can use raw public keys [RFC7250] 369 or the Cached Information Extension [RFC7924]. The Cached 370 Information Extension avoids transmitting the server's certificate 371 and certificate chain if the client has cached that information from 372 a previous TLS handshake. TLS False Start [RFC7918] can reduce round 373 trips by allowing the TLS second flight of messages 374 (ChangeCipherSpec) to also contain the (encrypted) Babel packet. 376 Appendix B. Acknowledgments 378 The authors would like to thank Donald Eastlake, Thomas Fossati, 379 Gabriel Kerneis, Antoni Przygienda, Henning Rogge, Dan Romascanu, 380 Barbara Stark, Markus Stenberg, Dave Taht, Martin Thomson, Sean 381 Turner and Martin Vigoureux for their input and contributions. The 382 performance considerations in this document were inspired from the 383 ones for DNS over DTLS [RFC8094]. 385 Authors' Addresses 387 Antonin Decimo 388 IRIF, University of Paris-Diderot 389 Paris 390 France 392 Email: antonin.decimo@gmail.com 394 David Schinazi 395 Google LLC 396 1600 Amphitheatre Parkway 397 Mountain View, California 94043 398 USA 400 Email: dschinazi.ietf@gmail.com 402 Juliusz Chroboczek 403 IRIF, University of Paris-Diderot 404 Case 7014 405 75205 Paris Cedex 13 406 France 408 Email: jch@irif.fr