idnits 2.17.1 draft-decimo-babel-dtls-01.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 draft header indicates that this document updates RFC6126bis, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2018) is 2123 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-05 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 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 Updates: 6126bis (if approved) D. Schinazi 5 Intended status: Standards Track Apple Inc. 6 Expires: January 3, 2019 J. Chroboczek 7 IRIF, University of Paris-Diderot 8 July 2, 2018 10 Babel Routing Protocol over Datagram Transport Layer Security 11 draft-decimo-babel-dtls-01 13 Abstract 15 This documents describes how to use Datagram Transport Layer Security 16 (DTLS) to secure the Babel Routing Protocol. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 3, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Specification of Requirements . . . . . . . . . . . . . . 3 54 2. Operation of the Protocol . . . . . . . . . . . . . . . . . . 3 55 3. Handling protected and unprotected data . . . . . . . . . . . 3 56 3.1. Cleartext and DTLS on the same port . . . . . . . . . . . 3 57 3.2. Cleartext and DTLS on separate ports . . . . . . . . . . 4 58 4. Establishing and handling Babel over DTLS sessions . . . . . 4 59 4.1. Session Initiation . . . . . . . . . . . . . . . . . . . 4 60 4.2. Transmission . . . . . . . . . . . . . . . . . . . . . . 4 61 4.3. Reception . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.4. Neighbour flush . . . . . . . . . . . . . . . . . . . . . 5 63 5. Interface MTU Issues . . . . . . . . . . . . . . . . . . . . 5 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 8.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Appendix A. Performance Considerations . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 Babel over DTLS is a security protocol for the Babel routing protocol 75 [RFC6126bis], that uses Datagram Transport Layer Security (DTLS) 76 [RFC6347]. This document describes how to protect Babel with Babel 77 over DTLS. 79 The motivation for proposing Babel over DTLS is that DTLS provides a 80 sub-layer of security that is well-defined, whose security has been 81 shown, and that has multiple implementations. Babel over DTLS has 82 the following properties, inherited from DTLS: 84 o authentication of peers; 86 o integrity of data; 88 o confidentiality of data; 90 o use of asymmetric keys. 92 The main change to the Babel protocol is that Babel over DTLS 93 requires most packets to be sent over unicast. 95 A malicious entity in range of a non-secured deployment of Babel can 96 learn properties of the network, but also reroute legitimate traffic 97 by advertising routes with a low metric. 99 1.1. Specification of Requirements 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in BCP 104 14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. 107 2. Operation of the Protocol 109 At first sight, there are incompatibilities between Babel and DTLS. 110 Babel is a pure peer-to-peer protocol, while DTLS is a two parties 111 client-server protocol. A Babel implementation typically uses 112 unicast and multicast, while DTLS can only protect unicast. 114 The problem of assigning a client of server role for a DTLS handshake 115 to Babel nodes is solved by a simple arbitrary choice. The addresses 116 of the two nodes are compared, and the node with the lowest address 117 acts as the server. 119 Babel is sufficiently flexible to work almost without multicast. In 120 Babel over DTLS, almost all packets are sent via unicast. Packets 121 that would have been sent via unicast needs to be duplicated and sent 122 to all of the original recipients via unicast. The cost of 123 duplication is balanced by the fact that on networks with low 124 throughput, unicast is often far more effective than multicast. Only 125 neighbour discovery packets are sent via multicast, as they do not 126 represent a security threat. 128 3. Handling protected and unprotected data 130 A Babel node needs to receive unprotected data for bootstrapping 131 reasons, as well as protected data. Protected and unprotected 132 traffic needs to be differentiated. 134 [ NOTE TO READER: AUTHORS ARE CONSIDERING THESE TWO OPTIONS BUT ONLY 135 ONE WILL BE RETAINED IN THE FINAL DOCUMENT. ] 137 3.1. Cleartext and DTLS on the same port 139 In this approach, Babel and Babel over DTLS traffic is received on 140 the same port. The DTLS client port, the DTLS server port, and the 141 Babel port (6696) are equal. When a packet is received, it is 142 unconditionally treated as a DTLS packet and decrypted. 144 o If the decryption is successful, the decrypted content is parsed 145 as a Babel packet and the node acts on it. 147 o Otherwise, the packet is parsed as a Babel packet and the node 148 MUST silently ignore all TLVs except Hello and IHU. 150 Since the source port is fixed as 6696, a node that loses its DTLS 151 state (e.g. if it reboots), will reuse the same source and 152 destination ports for the new session. In order to avoid discarding 153 these new packets, nodes receiving an unexpected DTLS ClientHello 154 MUST proceed with a new handshake and MUST NOT destroy the existing 155 session until the new session's handshake completes to avoid denial 156 of service attacks (Section 4.2.8 of [RFC6347]). 158 3.2. Cleartext and DTLS on separate ports 160 In this approach, a different port (number TBD) is allocated by IANA 161 for Babel over DTLS traffic. The Babel over DTLS server listens on 162 this port and Babel over DTLS clients use an ephemeral source port to 163 initiate outbound DTLS connections. Unprotected Babel messages are 164 sent and received over the standard Babel port (6696). When parsing 165 unprotected packets, all Babel TLVs except Hello and IHU MUST be 166 silently ignored. 168 4. Establishing and handling Babel over DTLS sessions 170 4.1. Session Initiation 172 When a node A acquires a new neighbour B (e.g. when A first receives 173 a Babel packet from B, see Section 3.4 of [RFC6126bis]), 175 o if the IP address A uses to send and receive Babel packets is 176 smaller than the source IP address of the received Babel packet 177 from B, A initialises its DTLS state as a server for peer B; 179 o otherwise, A initialises its DTLS state as a client for peer B, 180 and initiates a DTLS handshake. 182 Once the handshake succeeds and a DTLS session is established, nodes 183 send all unicast Babel messages over DTLS. 185 4.2. Transmission 187 Since DTLS cannot secure multicast, nodes SHOULD send all TLVs over 188 unicast DTLS, if possible. All TLVs that are not Hello nor IHU MUST 189 be sent over unicast DTLS. Hello and IHU TLVs MAY be sent either 190 over unicast DTLS or unprotected multicast. Nodes MUST NOT send any 191 unprotected packets over unicast. 193 4.3. Reception 195 Packets received over unicast DTLS are parsed the same way as any 196 packets in the original specification of Babel. Nodes MUST parse 197 unprotected packets received over multicast, however they MUST 198 silently ignore any TLV that is not Hello or IHU. Unprotected 199 packets received over unicast MUST be silently ignored. 201 4.4. Neighbour flush 203 When a neighbour entry is flushed from the neighbour table 204 (Appendix A of [RFC6126bis]), its associated DTLS state SHOULD be 205 discarded. The node MAY send a DTLS close_notify alert to the 206 neighbour. 208 5. Interface MTU Issues 210 Compared to normal Babel, DTLS adds at least 13 octets of header, 211 plus cipher and authentication overhead to every packet. This 212 reduces the size of the Babel payload that can be carried. 214 As stated in Section 4 of [RFC6126bis], in order to minimise the 215 number of packets being sent while avoiding lower-layer 216 fragmentation, a Babel node SHOULD attempt to maximise the size of 217 the packets it sends, up to the outgoing interface's MTU adjusted for 218 lower-layer headers (28 octets for UDP over IPv4, 48 octets for UDP 219 over IPv6). It MUST NOT send packets larger than the attached 220 interface's MTU adjusted for lower-layer headers or 512 octets, 221 whichever is larger, but not exceeding 2^16 - 1 adjusted for lower- 222 layer headers. Every Babel speaker MUST be able to receive packets 223 that are as large as any attached interface's MTU adjusted for lower- 224 layer headers or 512 octets, whichever is larger. Babel packets MUST 225 NOT be sent in IPv6 Jumbograms. 227 Theses requirements are retained by this specification, but are 228 extended to take DTLS overhead into account as follows. The Babel 229 node MUST ensure that the DTLS datagram size does not exceed the 230 interface MTU, i.e., each DTLS record MUST fit within a single 231 datagram, as required by [RFC6347]. A Babel node MUST consider the 232 amount of record expansion expected by the DTLS processing when 233 calculating the maximum size of Babel packet that fits within the 234 interface MTU. The overhead can be computed as DTLS overhead of 13 235 octets + authentication overhead of the negotiated DTLS cipher suite 236 + block padding (Section 4.1.1.1 of [RFC6347]). 238 6. IANA Considerations 240 If the final version of this specification uses the standard Babel 241 port for unprotected packets and DTLS Section 3.1, no actions are 242 required from IANA. 244 If the final version of this specification uses separate ports for 245 unprotected packets and DTLS Section 3.2, IANA is requested to assign 246 a UDP port with label "Babel_DTLS". 248 7. Security Considerations 250 The interaction between two Babel peers requires Datagram Transport 251 Layer Security (DTLS) with a cipher suite offering confidentiality 252 protection. The guidance given in [RFC7525] MUST be followed to 253 avoid attacks on DTLS. The DTLS client SHOULD use the TLS 254 Certificate Status Request extension (Section 8 of [RFC6066]). 256 A malicious client might attempt to perform a high number of DTLS 257 handshakes with a server. As the clients are not uniquely identified 258 by the protocol and can be obfuscated with IPv4 address sharing and 259 with IPv6 temporary addresses, a server needs to mitigate the impact 260 of such an attack. Such mitigation might involve rate limiting 261 handshakes from a given subnet or more advanced DoS/DDoS avoidance 262 techniques beyond the scope of this document. 264 8. References 266 8.1. Normative References 268 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 269 Requirement Levels", BCP 14, RFC 2119, 270 DOI 10.17487/RFC2119, March 1997, 271 . 273 [RFC6126bis] 274 Chroboczek, J. and D. Schinazi, "The Babel Routing 275 Protocol", Internet Draft draft-ietf-babel-rfc6126bis-05, 276 October 2017. 278 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 279 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 280 January 2012, . 282 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 283 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 284 May 2017, . 286 8.2. Informative References 288 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 289 Extensions: Extension Definitions", RFC 6066, 290 DOI 10.17487/RFC6066, January 2011, 291 . 293 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 294 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 295 Transport Layer Security (TLS) and Datagram Transport 296 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 297 June 2014, . 299 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 300 "Recommendations for Secure Use of Transport Layer 301 Security (TLS) and Datagram Transport Layer Security 302 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 303 2015, . 305 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 306 Layer Security (TLS) False Start", RFC 7918, 307 DOI 10.17487/RFC7918, August 2016, 308 . 310 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 311 (TLS) Cached Information Extension", RFC 7924, 312 DOI 10.17487/RFC7924, July 2016, 313 . 315 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 316 Transport Layer Security (DTLS)", RFC 8094, 317 DOI 10.17487/RFC8094, February 2017, 318 . 320 Appendix A. Performance Considerations 322 To reduce the number of octets taken by the DTLS handshake, 323 especially the size of the certificate in the ServerHello (which can 324 be several kilobytes), Babel peers can use raw public keys [RFC7250] 325 or the Cached Information Extension [RFC7924]. The Cached 326 Information Extension avoids transmitting the server's certificate 327 and certificate chain if the client has cached that information from 328 a previous TLS handshake. TLS False Start [RFC7918] can reduce round 329 trips by allowing the TLS second flight of messages 330 (ChangeCipherSpec) to also contain the (encrypted) Babel packet. 332 These performance considerations were inspired from the ones for DNS 333 over DTLS [RFC8094]. 335 Authors' Addresses 337 Antonin Decimo 338 IRIF, University of Paris-Diderot 339 Paris 340 France 342 Email: antonin.decimo@gmail.com 344 David Schinazi 345 Apple Inc. 346 One Apple Park Way 347 Cupertino, California 95014 348 USA 350 Email: dschinazi@apple.com 352 Juliusz Chroboczek 353 IRIF, University of Paris-Diderot 354 Case 7014 355 75205 Paris Cedex 13 356 France 358 Email: jch@irif.fr