idnits 2.17.1 draft-tschofenig-tls-dtls-rrc-00.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 document seems to lack a Security Considerations section. ** There are 4 instances of too long lines in the document, the longest one being 4 characters in excess of 72. -- The draft header indicates that this document updates RFC6347, 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 (Using the creation date from RFC6347, updated by this document, for RFC5378 checks: 2008-06-09) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 08, 2019) is 1747 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 360 -- Looks like a reference, but probably isn't: '2' on line 362 -- Looks like a reference, but probably isn't: '3' on line 365 == Unused Reference: 'RFC5246' is defined on line 324, but no explicit reference was found in the text == Unused Reference: 'RFC6347' is defined on line 329, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-tls-dtls-connection-id-05 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-31 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS T. Fossati 3 Internet-Draft H. Tschofenig, Ed. 4 Updates: 6347 (if approved) Arm Limited 5 Intended status: Standards Track July 08, 2019 6 Expires: January 9, 2020 8 Return Routability Check for DTLS 1.2 and DTLS 1.3 9 draft-tschofenig-tls-dtls-rrc-00 11 Abstract 13 This document specifies a return routability check for use in context 14 of the Connection ID (CID) construct for the Datagram Transport Layer 15 Security (DTLS) protocol versions 1.2 and 1.3. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 9, 2020. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 This document may contain material from IETF Documents or IETF 50 Contributions published or made publicly available before November 51 10, 2008. The person(s) controlling the copyright in some of this 52 material may not have granted the IETF Trust the right to allow 53 modifications of such material outside the IETF Standards Process. 54 Without obtaining an adequate license from the person(s) controlling 55 the copyright in such materials, this document may not be modified 56 outside the IETF Standards Process, and derivative works of it may 57 not be created outside the IETF Standards Process, except to format 58 it for publication as an RFC or to translate it into languages other 59 than English. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 65 3. Application Layer Return Routability Check . . . . . . . . . 3 66 4. The Return Routability Check Message . . . . . . . . . . . . 4 67 5. RRC Example . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 6. Security and Privacy Considerations . . . . . . . . . . . . . 7 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 9. Normative References . . . . . . . . . . . . . . . . . . . . 7 72 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 9 73 Appendix B. Working Group Information . . . . . . . . . . . . . 9 74 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 In "classical" DTLS, selecting a security context of an incoming DTLS 80 record is accomplished with the help of the 5-tuple, i.e. source IP 81 address, source port, transport protocol, destination IP address, and 82 destination port. Changes to this 5 tuple can happen for a variety 83 reasons over the lifetime of the DTLS session. In the IoT content 84 NAT rebinding is a common reason with sleepy devices. Other examples 85 include end host mobility and multi-homing. Without CID, if the 86 source IP address and/or source port changes during the lifetime of 87 an ongoing DTLS session then the receiver will be unable to locate 88 the correct security context. As a result, the DTLS handshake has to 89 be re-run. 91 A CID is an identifier carried in the record layer header of a DTLS 92 datagram that gives the receiver additional information for selecting 93 the appropriate security context. The CID mechanism has been 94 specified in [I-D.ietf-tls-dtls-connection-id] for DTLS 1.2 and in 95 [I-D.ietf-tls-dtls13] for DTLS 1.3. 97 An on-path adversary could intercept and modify the source IP address 98 (and the source port). Even if receiver checks the authenticity and 99 freshness of the packet, the recipient is fooled into changing the 100 CID-to-IP/port association. This attack is possible because the 101 network and transport layer identifiers, such as source IP address 102 and source port numbers, are not integrity protected and 103 authenticated by the DTLS record layer. 105 This attack makes strong assumptions on the attacker's abilities, and 106 moreover it only misleads the peer until the next message gets 107 through un-intercepted. 109 A return routability check (RRC) is performed by the receiving peer 110 before the CID-to-IP address/port binding is updated in that peer's 111 session state database. This is done in order to provide a certain 112 degree of confidence to the receiving peer that the sending peer is 113 reachable at the indicated address and port. 115 Without such a return routability check, an adversary can redirect 116 traffic towards a third party or a black hole. 118 While an equivalent check can be performed at the application layer 119 (modulo the DTLS API exposing the address update event to the calling 120 application), it is advantageous to offer this functionality at the 121 DTLS layer. Section 3 describes the application layer procedure and 122 Section 4 specifies a new message to perform this return routability 123 check. 125 2. Conventions and Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 This document assumes familiarity with the CID solutions defined for 134 DTLS 1.2 [I-D.ietf-tls-dtls-connection-id] and for DTLS 1.3 135 [I-D.ietf-tls-dtls13]. 137 3. Application Layer Return Routability Check 139 When a record with CID is received that has the source address of the 140 enclosing UDP datagram different from the one previously associated 141 with that CID, the receiver MUST NOT update its view of the peer's IP 142 address and port number with the source specified in the UDP datagram 143 before cryptographically validating the enclosed record(s). This is 144 to ensure that a man-on-the-middle attacker that sends a datagram 145 with a different source address/port on an existing CID session does 146 not successfully manage to re-route any return traffic. 148 Furthermore, when using CID, anti-replay protection MUST be enabled. 149 This is to ensure that a man-on-the-middle attacker sending a 150 previously captured record with a modified source IP address and port 151 will not be able to successfully pass the above check (since the 152 datagram is very likely discarded on receipt - if it falls outside 153 the replay window). 155 The two countermeasures cannot complete stop a man-in-the-middle 156 attacker who performs a DoS on the sender or uses the receiver as as 157 backscatter source for a DDoS attack. For a more generic protection, 158 a return routability check is needed. 160 It is RECOMMENDED that implementations of the CID functionaliy 161 described in [I-D.ietf-tls-dtls-connection-id] and in 162 [I-D.ietf-tls-dtls13] added peer address update events to their APIs. 163 Applications can then use these events as triggers to perform an 164 application layer return routability check, for example one that is 165 based on successful exchange of minimal amount of ping-pong traffic 166 with the peer. 168 4. The Return Routability Check Message 170 enum { 171 invalid(0), 172 change_cipher_spec(20), 173 alert(21), 174 handshake(22), 175 application_data(23), 176 heartbeat(24), /* RFC 6520 */ 177 return_routability_check(TBD), /* NEW */ 178 (255) 179 } ContentType; 181 The newly introduced return_routability_check message contains a 182 cookie. The semantic of the cookie is similar to the cookie used in 183 the HelloRetryRequest message defined in [RFC8446]. 185 The return_routability_check message MUST be authenticated and 186 encrypted using the currently active security context. 188 The endpoint that observes the peer's address update MUST stop 189 sending any buffered application data (or limit the sending rate to a 190 TBD threshold) and initiate the return routability check that 191 proceeds as follows: 193 1. A cookie is placed in the return_routability_check message; 195 2. The message is sent to the observed new address and a timeout T 196 is started; 198 3. The peer endpoint, after successfully verifying the received 199 return_routability_check message echoes it back; 201 4. When the initiator receives and verifies the 202 return_routability_check message, it updates the peer address 203 binding; 205 5. If T expires, or the address confirmation fails, the peer address 206 binding is not updated. 208 After this point, any pending send operation is resumed to the bound 209 peer address. 211 struct { 212 opaque cookie<1..2^16-1>; 213 } Cookie; 215 struct { 216 Cookie cookie; 217 } return_routability_check; 219 5. RRC Example 221 The example shown in Figure 1 illustrates a client and a server 222 exchanging application payloads protected by DTLS with an 223 unilaterally used CIDs. At some point in the communication 224 interaction the IP address used by the client changes and, thanks to 225 the CID usage, the security context to interpret the record is 226 successfully located by the server. However, the server wants to 227 test the reachability of the client at his new IP address, to avoid 228 being abused (e.g., as an amplifier) by an attacker impersonating the 229 client. 231 Client Server 232 ------ ------ 234 Application Data ========> 235 236 Src-IP=A 237 Dst-IP=Z 238 <======== Application Data 239 Src-IP=Z 240 Dst-IP=A 242 <<------------->> 243 << Some >> 244 << Time >> 245 << Later >> 246 <<------------->> 248 Application Data ========> 249 250 Src-IP=B 251 Dst-IP=Z 253 <<< Unverified IP 254 Address B >> 256 <-------- Return Routability Check 257 (cookie) 258 Src-IP=Z 259 Dst-IP=B 261 Return Routability Check --------> 262 (cookie) 263 Src-IP=B 264 Dst-IP=Z 266 <<< IP Address B 267 Verified >> 269 <======== Application Data 270 Src-IP=Z 271 Dst-IP=B 273 Figure 1: Return Routability Example 275 6. Security and Privacy Considerations 277 As all the datagrams in DTLS are authenticated, integrity and 278 confidentiality protected there is no risk that an attacker 279 undetectably modifies the contents of those packets. The IP 280 addresses in the IP header and the port numbers of the transport 281 layer are, however, not authenticated. With the introduction of the 282 CID, care must be taken to test reachability of a peer at a given IP 283 address and port. 285 Note that the return routability checks do not protect against third- 286 party flooding if the attacker is along the path, as the attacker can 287 forward the return routability checks to the real peer (even if those 288 datagrams are cryptographically authenticated). 290 7. IANA Considerations 292 IANA is requested to allocate an entry to the existing TLS 293 "ContentType" registry, for the return_routability_check(TBD) defined 294 in this document. 296 8. Open Issues 298 - Should the return routability check use separate sequence numbers 299 and replay windows? 301 - Should the heartbeat message be re-used instead of the proposed 302 new message exchange? 304 9. References 306 9.1. Normative References 308 [I-D.ietf-tls-dtls-connection-id] 309 Rescorla, E., Tschofenig, H., and T. Fossati, "Connection 310 Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection- 311 id-05 (work in progress), May 2019. 313 [I-D.ietf-tls-dtls13] 314 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 315 Datagram Transport Layer Security (DTLS) Protocol Version 316 1.3", draft-ietf-tls-dtls13-31 (work in progress), March 317 2019. 319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 320 Requirement Levels", BCP 14, RFC 2119, 321 DOI 10.17487/RFC2119, March 1997, 322 . 324 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 325 (TLS) Protocol Version 1.2", RFC 5246, 326 DOI 10.17487/RFC5246, August 2008, 327 . 329 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 330 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 331 January 2012, . 333 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 334 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 335 May 2017, . 337 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 338 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 339 . 341 9.2. URIs 343 [1] mailto:tls@ietf.org 345 [2] https://www1.ietf.org/mailman/listinfo/tls 347 [3] https://www.ietf.org/mail-archive/web/tls/current/index.html 349 Appendix A. History 351 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 353 - Initial version 355 Appendix B. Working Group Information 357 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 359 The discussion list for the IETF TLS working group is located at the 360 e-mail address tls@ietf.org [1]. Information on the group and 361 information on how to subscribe to the list is at 362 https://www1.ietf.org/mailman/listinfo/tls [2] 364 Archives of the list can be found at: https://www.ietf.org/mail- 365 archive/web/tls/current/index.html [3] 367 Appendix C. Acknowledgements 369 We would like to thank Achim Kraus, Hanno Becker and Manuel Pegourie- 370 Gonnard for their input to this document. 372 Authors' Addresses 374 Thomas Fossati 375 Arm Limited 377 EMail: thomas.fossati@arm.com 379 Hannes Tschofenig (editor) 380 Arm Limited 382 EMail: hannes.tschofenig@arm.com