idnits 2.17.1 draft-ietf-babel-dtls-02.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 (November 14, 2018) is 1961 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-07 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-12) exists of draft-ietf-babel-hmac-01 == Outdated reference: A later version (-13) exists of draft-ietf-tls-dtls-connection-id-02 -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 1 error (**), 0 flaws (~~), 4 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 Google LLC 6 Expires: May 18, 2019 J. Chroboczek 7 IRIF, University of Paris-Diderot 8 November 14, 2018 10 Babel Routing Protocol over Datagram Transport Layer Security 11 draft-ietf-babel-dtls-02 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 May 18, 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 . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . 5 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 6.2. Informative References . . . . . . . . . . . . . . . . . 6 71 Appendix A. Performance Considerations . . . . . . . . . . . . . 7 72 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 documents describes 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 very basic features, 103 namely authentication, integrity and replay protection with a small 104 number of symmetric keys. 106 Since HMAC authentication is simpler, requires fewer changes to the 107 Babel protocol, and avoids a dependency on DTLS, its use is 108 RECOMMENDED in deployments where both protocols are equally 109 applicable. 111 2. Operation of the Protocol 113 Babel over DTLS requires some changes to how Babel operates. First, 114 DTLS is a client-server protocol, while Babel is a peer-to-peer 115 protocol. Second, DTLS can only protect unicast communication, while 116 Babel packets can be sent over to both unicast and multicast 117 destinations. 119 2.1. DTLS Connection Initiation 121 All Babel over DTLS nodes MUST act as DTLS servers on the "babel- 122 dtls" port (UDP port TBD), and MUST listen for traffic on the 123 unencrypted "babel" port (UDP port 6696). When a Babel node 124 discovers a new neighbor (generally by receiving an unencrypted 125 multicast Babel packet), it compares the neighbour's IPv6 link-local 126 address with its own, using network byte ordering. If a node's 127 address is lower than the recently discovered neighbor's address, it 128 acts as a client and connects to the neighbor. In other words, the 129 node with the lowest address is the DTLS client for this pairwise 130 relationship. As an example, fe80::1:2 is considered lower than 131 fe80::2:1. 133 The node acting as DTLS client initiates its DTLS connection from an 134 ephemeral UDP port. Nodes SHOULD ensure that new client DTLS 135 connections use different ephemeral ports from recently used 136 connections to allow servers to differentiate between the new and old 137 DTLS connections. Alternatively, nodes MAY use DTLS connection 138 identifiers [DTLS-CID] as a higher-entropy mechanism to distinguish 139 between connections. 141 When a node receives a new DTLS connection, it MUST verify the source 142 IP address, and reject the connection if the address is not an IPv6 143 link-local address. Nodes MUST use mutual authentication 144 (authenticating both client and server); servers MUST request client 145 authentication by sending a CertificateRequest message. If either 146 node fails to verify the peer's authentication, it MUST abort the 147 DTLS handshake. Nodes MUST only negotiate DTLS version 1.2 or 148 higher. 150 2.2. Protocol Encoding 152 Babel over DTLS sends all unicast Babel packets protected by DTLS. 153 The entire Babel packet, from the Magic byte at the start of the 154 Babel header to the last byte of the Babel packet trailer, is sent 155 protected by DTLS. 157 2.3. Transmission 159 When sending packets, Babel over DTLS nodes MUST NOT send any TLVs 160 over the unprotected "babel" port, with the exception of Hello TLVs 161 without the Unicast flag set. Babel over DTLS nodes MUST NOT send 162 any unprotected unicast packets. This ensures the confidentiality of 163 the information sent in Babel packets (e.g. the network topology) by 164 only sending it encrypted by DTLS. Unless some out-of-band neighbor 165 discovery mechanism is available, nodes SHOULD periodically send 166 unprotected multicast Hellos to ensure discovery of new neighbours. 167 In order to maintain bidirectional reachability, nodes can either 168 rely entirely on unprotected multicast Hellos, or send protected 169 unicast Hellos in addition to the multicast Hellos. 171 Since Babel over DTLS only protects unicast packets, implementors may 172 implement Babel over DTLS by modifying an unprotected implementation 173 of Babel, and replacing any TLV sent over multicast with a separate 174 TLV sent over unicast for each neighbour. 176 2.4. Reception 178 Babel over DTLS nodes can receive Babel packets either protected over 179 a DTLS connection, or unprotected directly over the "babel" port. To 180 ensure the security properties of this mechanism, unprotected packets 181 are treated differently. Nodes MUST silently ignore any unprotected 182 packet sent over unicast. When parsing an unprotected packet, a node 183 MUST silently ignore all TLVs that are not of type Hello. Nodes MUST 184 also silently ignore any unprotected Hello with the Unicast flag set. 185 Note that receiving an unprotected packet can still be used to 186 discover new neighbors, even when all TLVs in that packet are 187 silently ignored. 189 2.5. Neighbour table entry 191 It is RECOMMENDED for nodes to associate the state of their DTLS 192 connection with their neighbour table. When a neighbour entry is 193 flushed from the neighbour table (Appendix A of [RFC6126bis]), its 194 associated DTLS state SHOULD be discarded. The node SHOULD send a 195 DTLS close_notify alert to the neighbour if it believes the link is 196 still viable. 198 2.6. Simultaneous operation of both Babel over DTLS and unprotected 199 Babel 201 Implementations MAY implement both Babel over DTLS and unprotected 202 Babel. However, accepting unprotected Babel packets (other than 203 multicast Hellos) loses the security properties of Babel over DTLS. 204 A node MAY allow configuration options to allow unprotected Babel on 205 some interfaces but not others; this effectively gives nodes on that 206 interface the same access as authenticated nodes, and SHOULD NOT be 207 done unless that interface has a mechanism to authenticate nodes at a 208 lower layer (e.g. IPsec). 210 3. Interface Maximum Transmission Unit Issues 212 Compared to unprotected Babel, DTLS adds header, authentication tag 213 and possibly block-size padding overhead to every packet. This 214 reduces the size of the Babel payload that can be carried. This 215 document does not relax the packet size requirements in Section 4 of 216 [RFC6126bis], but recommends that DTLS overhead be taken into account 217 when computing maximum packet size. 219 More precisely, nodes SHOULD compute the overhead of DTLS depending 220 on the ciphers in use, and SHOULD NOT send Babel packets larger than 221 the interface maximum transmission unit (MTU) minus the overhead of 222 IP, UDP and DTLS. Nodes MUST NOT send Babel packets larger than the 223 attached interface's MTU adjusted for known lower-layer headers (at 224 least UDP and IP) or 512 octets, whichever is larger, but not 225 exceeding 2^16 - 1 adjusted for lower-layer headers. Every Babel 226 speaker MUST be able to receive packets that are as large as any 227 attached interface's MTU adjusted for UDP and IP headers or 512 228 octets, whichever is larger. Note that this requirement on reception 229 does not take into account the overhead of DTLS because the peer may 230 not have the ability to compute the overhead of DTLS and the packet 231 may be fragmented by lower layers. 233 4. IANA Considerations 235 If this document is approved, IANA is requested to register a UDP 236 port number, called "babel-dtls", for use by Babel over DTLS. 238 5. Security Considerations 240 The interaction between two Babel peers requires Datagram Transport 241 Layer Security (DTLS) with a cipher suite offering confidentiality 242 protection. The guidance given in [RFC7525] MUST be followed to 243 avoid attacks on DTLS. 245 A malicious client might attempt to perform a high number of DTLS 246 handshakes with a server. As the clients are not uniquely identified 247 by the protocol and can be obfuscated with IPv4 address sharing and 248 with IPv6 temporary addresses, a server needs to mitigate the impact 249 of such an attack. Such mitigation might involve rate limiting 250 handshakes from a given subnet or more advanced denial of service 251 avoidance techniques beyond the scope of this document. 253 6. References 255 6.1. Normative References 257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 258 Requirement Levels", BCP 14, RFC 2119, 259 DOI 10.17487/RFC2119, March 1997, 260 . 262 [RFC6126bis] 263 Chroboczek, J. and D. Schinazi, "The Babel Routing 264 Protocol", Internet Draft draft-ietf-babel-rfc6126bis-07, 265 November 2018. 267 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 268 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 269 January 2012, . 271 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 272 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 273 May 2017, . 275 6.2. Informative References 277 [BABEL-HMAC] 278 Do, C., Kolodziejak, W., and J. Chroboczek, "Babel 279 Cryptographic Authentication", Internet Draft draft-ietf- 280 babel-hmac-01, November 2018. 282 [DTLS-CID] 283 Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom, 284 "Connection Identifiers for DTLS 1.2", Internet Draft 285 draft-ietf-tls-dtls-connection-id-02, October 2018. 287 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 288 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 289 Transport Layer Security (TLS) and Datagram Transport 290 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 291 June 2014, . 293 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 294 "Recommendations for Secure Use of Transport Layer 295 Security (TLS) and Datagram Transport Layer Security 296 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 297 2015, . 299 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 300 Layer Security (TLS) False Start", RFC 7918, 301 DOI 10.17487/RFC7918, August 2016, 302 . 304 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 305 (TLS) Cached Information Extension", RFC 7924, 306 DOI 10.17487/RFC7924, July 2016, 307 . 309 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 310 Transport Layer Security (DTLS)", RFC 8094, 311 DOI 10.17487/RFC8094, February 2017, 312 . 314 Appendix A. Performance Considerations 316 To reduce the number of octets taken by the DTLS handshake, 317 especially the size of the certificate in the ServerHello (which can 318 be several kilobytes), Babel peers can use raw public keys [RFC7250] 319 or the Cached Information Extension [RFC7924]. The Cached 320 Information Extension avoids transmitting the server's certificate 321 and certificate chain if the client has cached that information from 322 a previous TLS handshake. TLS False Start [RFC7918] can reduce round 323 trips by allowing the TLS second flight of messages 324 (ChangeCipherSpec) to also contain the (encrypted) Babel packet. 326 Appendix B. Acknowledgments 328 The authors would like to thank Thomas Fossati, Gabriel Kerneis, 329 Antoni Przygienda, Markus Stenberg, Dave Taht, and Martin Thomson for 330 their input and contributions. The performance considerations in 331 this document were inspired from the ones for DNS over DTLS 332 [RFC8094]. 334 Authors' Addresses 336 Antonin Decimo 337 IRIF, University of Paris-Diderot 338 Paris 339 France 341 Email: antonin.decimo@gmail.com 343 David Schinazi 344 Google LLC 345 1600 Amphitheatre Parkway 346 Mountain View, California 94043 347 USA 349 Email: dschinazi.ietf@gmail.com 351 Juliusz Chroboczek 352 IRIF, University of Paris-Diderot 353 Case 7014 354 75205 Paris Cedex 13 355 France 357 Email: jch@irif.fr