idnits 2.17.1 draft-ietf-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. -- The abstract seems to indicate that this document updates RFC6126, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 8, 2018) is 2027 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) == Outdated reference: A later version (-12) exists of draft-ietf-babel-hmac-00 -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 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: April 11, 2019 J. Chroboczek 7 IRIF, University of Paris-Diderot 8 October 8, 2018 10 Babel Routing Protocol over Datagram Transport Layer Security 11 draft-ietf-babel-dtls-01 13 Abstract 15 The Babel Routing Protocol does not contain any means to authenticate 16 neighbours or protect messages sent between them. This documents 17 describes a mechanism to ensure these properties, using Datagram 18 Transport Layer Security (DTLS). This document updates RFC 6126bis. 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 April 11, 2019. 37 Copyright Notice 39 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.5. Neighbour table entry . . . . . . . . . . . . . . . . . . 4 63 3. Interface Maximum Transmission Unit Issues . . . . . . . . . 5 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 6.2. Informative References . . . . . . . . . . . . . . . . . 6 69 Appendix A. Performance Considerations . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 The Babel Routing Protocol [RFC6126bis] does not contain any means to 75 authenticate neighbours or protect messages sent between them. 76 Because of this, an attacker is able to send maliciously crafted 77 Babel messages which could lead a network to route traffic to an 78 attacker or to an under-resourced target causing denial of service. 79 This documents describes a mechanism to prevent such attacks, using 80 Datagram Transport Layer Security (DTLS) [RFC6347]. 82 1.1. Specification of Requirements 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 86 "OPTIONAL" in this document are to be interpreted as described in BCP 87 14 [RFC2119] [RFC8174] when, and only when, they appear in all 88 capitals, as shown here. 90 1.2. Applicability 92 The current two main mechanisms for securing Babel are Babel over 93 DTLS (as described in this document) and Babel Cryptographic 94 Authentication [BabelHMAC]. The latter has the advantages of being 95 simpler and not requiring a dependency on DTLS, therefore 96 implementers are encouraged to consider it in preference to the 97 mechanism defined in this document whenever both are applicable to a 98 given deployment. Both mechanisms ensure integrity of messages and 99 prevent message replay. 101 However, DTLS offers several features that are not provided by Babel 102 Cryptographic Authentication, therefore Babel over DTLS is applicable 103 in cases where those features are needed. Examples of such features 104 include: 106 o Asymmetric keys. DTLS allows authentication via asymmetric keys, 107 which allows a finer granularity of trust per-peer, and allows for 108 revocation. 110 o Confidentiality of data. DTLS encrypts payloads, preventing an 111 on-link attacker from observing the routing table. 113 2. Operation of the Protocol 115 Babel over DTLS requires changes to how Babel is operated, for two 116 reasons. Firstly, because DTLS introduces the concepts of client and 117 server, while Babel is a peer-to-peer protocol. Secondly, DTLS can 118 only protect unicast, while Babel TLVs can be sent over both unicast 119 and multicast. 121 2.1. DTLS Connection Initiation 123 All Babel over DTLS nodes MUST act as DTLS servers on the "babel- 124 dtls" port (UDP port TBD), and MUST listen for multicast traffic on 125 the unencrypted "babel" port (UDP port 6696). When a Babel node 126 discovers a new neighbor (generally by receiving an unencrypted 127 multicast Babel packet), it compares the neighbour's IPv6 link-local 128 address with its own, using network byte ordering. If a node's 129 address is lower than the recently discovered neighbor's address, it 130 acts as a client and connects to the neighbor. In other words, the 131 node with the lowest address is the DTLS client for this pairwise 132 relationship. As an example, fe80::1:2 is considered lower than 133 fe80::2:1. The node acting as DTLS client initiates its DTLS 134 connection from an ephemeral UDP port. Nodes SHOULD ensure that new 135 client DTLS connections use different ephemeral ports from recently 136 used connections to allow servers to differentiate between the new 137 and old DTLS connections. When a node receives a new DTLS 138 connection, it MUST verify the source IP address, and reject the 139 connection if the address is not an IPv6 link-local address. 141 2.2. Protocol Encoding 143 Babel over DTLS sends all unicast Babel packets encrypted by DTLS. 144 The entire Babel packet, from the Magic byte at the start of the 145 Babel header to the last byte of the Babel packet trailer, is sent 146 protected by DTLS. 148 2.3. Transmission 150 When sending packets, Babel over DTLS nodes MUST NOT send any TLVs 151 over the unprotected "babel" port, with the exception of Hello TLVs 152 without the Unicast flag set. Babel over DTLS nodes MUST NOT send 153 any unprotected unicast packet. Unless some out-of-band neighbor 154 discovery mechanism is available, nodes SHOULD periodically send 155 unprotected multicast Hellos to ensure discovery of new neighbours. 156 In order to maintain bidirectional reachability, nodes can either 157 rely on unprotected multicast Hellos, or also send protected unicast 158 Hellos. 160 Since Babel over DTLS only protects unicast packets, implementors may 161 implement Babel over DTLS by modifying an unprotected implementation 162 of Babel, and replacing any TLV sent over multicast with a separate 163 TLV sent over unicast for each neighbour. 165 2.4. Reception 167 Babel over DTLS nodes can receive Babel packets either protected over 168 a DTLS connection, or unprotected directly over the "babel" port. To 169 ensure the security properties of this mechanism, unprotected packets 170 are treated differently. Nodes MUST silently ignore any unprotected 171 packet sent over unicast. When parsing an unprotected packet, a node 172 MUST silently ignore all TLVs that are not of type Hello. Nodes MUST 173 also silently ignore any unprotected Hello with the Unicast flag set. 174 Note that receiving an unprotected packet can still be used to 175 discover new neighbors, even when all TLVs in that packet are 176 silently ignored. 178 2.5. Neighbour table entry 180 It is RECOMMENDED for nodes to associate the state of their DTLS 181 connection with their neighbour table. When a neighbour entry is 182 flushed from the neighbour table (Appendix A of [RFC6126bis]), its 183 associated DTLS state SHOULD be discarded. The node MAY send a DTLS 184 close_notify alert to the neighbour. 186 3. Interface Maximum Transmission Unit Issues 188 Compared to unprotected Babel, DTLS adds header, authentication tag 189 and possibly block-size padding overhead to every packet. This 190 reduces the size of the Babel payload that can be carried. Nodes 191 SHOULD compute the overhead of DTLS depending on the ciphers in use, 192 and SHOULD NOT send Babel packets larger than the interface maximum 193 transmission unit (MTU) minus the overhead of lower layers (IP, UDP 194 and DTLS). This helps reduce the likelihood of lower-layer 195 fragmentation which would negatively impact performance and 196 reliability. Nodes MUST NOT send Babel packets larger than the 197 attached interface's MTU adjusted for known lower-layer headers (at 198 least UDP and IP) or 512 octets, whichever is larger, but not 199 exceeding 2^16 - 1 adjusted for lower-layer headers. Every Babel 200 speaker MUST be able to receive packets that are as large as any 201 attached interface's MTU adjusted for UDP and IP headers or 512 202 octets, whichever is larger. Note that this requirement on reception 203 does not take into account the overhead of DTLS because the peer may 204 not have the ability to compute the overhead of DTLS and the packet 205 may be fragmented by lower layers. Babel packets MUST NOT be sent in 206 IPv6 Jumbograms. 208 4. IANA Considerations 210 If this document is approved, IANA is requested to register a UDP 211 port number, called "babel-dtls", for use by Babel over DTLS. 213 5. Security Considerations 215 The interaction between two Babel peers requires Datagram Transport 216 Layer Security (DTLS) with a cipher suite offering confidentiality 217 protection. The guidance given in [RFC7525] MUST be followed to 218 avoid attacks on DTLS. The DTLS client SHOULD use the TLS 219 Certificate Status Request extension (Section 8 of [RFC6066]). 221 A malicious client might attempt to perform a high number of DTLS 222 handshakes with a server. As the clients are not uniquely identified 223 by the protocol and can be obfuscated with IPv4 address sharing and 224 with IPv6 temporary addresses, a server needs to mitigate the impact 225 of such an attack. Such mitigation might involve rate limiting 226 handshakes from a given subnet or more advanced denial of service 227 avoidance techniques beyond the scope of this document. 229 6. References 230 6.1. Normative References 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, 234 DOI 10.17487/RFC2119, March 1997, 235 . 237 [RFC6126bis] 238 Chroboczek, J. and D. Schinazi, "The Babel Routing 239 Protocol", Internet Draft draft-ietf-babel-rfc6126bis-05, 240 May 2018. 242 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 243 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 244 January 2012, . 246 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 247 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 248 May 2017, . 250 6.2. Informative References 252 [BabelHMAC] 253 Do, C., Kolodziejak, W., and J. Chroboczek, "Babel 254 Cryptographic Authentication", Internet Draft draft-ietf- 255 babel-hmac-00, August 2018. 257 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 258 Extensions: Extension Definitions", RFC 6066, 259 DOI 10.17487/RFC6066, January 2011, 260 . 262 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 263 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 264 Transport Layer Security (TLS) and Datagram Transport 265 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 266 June 2014, . 268 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 269 "Recommendations for Secure Use of Transport Layer 270 Security (TLS) and Datagram Transport Layer Security 271 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 272 2015, . 274 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 275 Layer Security (TLS) False Start", RFC 7918, 276 DOI 10.17487/RFC7918, August 2016, 277 . 279 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 280 (TLS) Cached Information Extension", RFC 7924, 281 DOI 10.17487/RFC7924, July 2016, 282 . 284 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 285 Transport Layer Security (DTLS)", RFC 8094, 286 DOI 10.17487/RFC8094, February 2017, 287 . 289 Appendix A. Performance Considerations 291 To reduce the number of octets taken by the DTLS handshake, 292 especially the size of the certificate in the ServerHello (which can 293 be several kilobytes), Babel peers can use raw public keys [RFC7250] 294 or the Cached Information Extension [RFC7924]. The Cached 295 Information Extension avoids transmitting the server's certificate 296 and certificate chain if the client has cached that information from 297 a previous TLS handshake. TLS False Start [RFC7918] can reduce round 298 trips by allowing the TLS second flight of messages 299 (ChangeCipherSpec) to also contain the (encrypted) Babel packet. 301 These performance considerations were inspired from the ones for DNS 302 over DTLS [RFC8094]. 304 Authors' Addresses 306 Antonin Decimo 307 IRIF, University of Paris-Diderot 308 Paris 309 France 311 Email: antonin.decimo@gmail.com 313 David Schinazi 314 Apple Inc. 315 One Apple Park Way 316 Cupertino, California 95014 317 USA 319 Email: dschinazi@apple.com 320 Juliusz Chroboczek 321 IRIF, University of Paris-Diderot 322 Case 7014 323 75205 Paris Cedex 13 324 France 326 Email: jch@irif.fr