idnits 2.17.1 draft-ietf-tls-dtls-rrc-03.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. -- 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 == Line 302 has weird spacing: '... + rrc v...' (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 (December 21, 2021) is 851 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) == Outdated reference: A later version (-09) exists of draft-ietf-uta-tls13-iot-profile-03 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS H. Tschofenig, Ed. 3 Internet-Draft T. Fossati, Ed. 4 Updates: 6347 (if approved) Arm Limited 5 Intended status: Standards Track December 21, 2021 6 Expires: June 24, 2022 8 Return Routability Check for DTLS 1.2 and DTLS 1.3 9 draft-ietf-tls-dtls-rrc-03 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 June 24, 2022. 34 Copyright Notice 36 Copyright (c) 2021 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. RRC Extension . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. The Return Routability Check Message . . . . . . . . . . . . 4 67 5. Path Validation Procedure . . . . . . . . . . . . . . . . . . 5 68 5.1. Path Challenge Requirements . . . . . . . . . . . . . . . 5 69 5.2. Path Response Requirements . . . . . . . . . . . . . . . 6 70 5.3. Timer Choice . . . . . . . . . . . . . . . . . . . . . . 6 71 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 7. Security and Privacy Considerations . . . . . . . . . . . . . 10 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 11.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 In "classical" DTLS, selecting a security context of an incoming DTLS 85 record is accomplished with the help of the 5-tuple, i.e. source IP 86 address, source port, transport protocol, destination IP address, and 87 destination port. Changes to this 5 tuple can happen for a variety 88 reasons over the lifetime of the DTLS session. In the IoT context, 89 NAT rebinding is common with sleepy devices. Other examples include 90 end host mobility and multi-homing. Without CID, if the source IP 91 address and/or source port changes during the lifetime of an ongoing 92 DTLS session then the receiver will be unable to locate the correct 93 security context. As a result, the DTLS handshake has to be re-run. 94 Of course, it is not necessary to re-run the full handshake if 95 session resumption is supported and negotiated. 97 A CID is an identifier carried in the record layer header of a DTLS 98 datagram that gives the receiver additional information for selecting 99 the appropriate security context. The CID mechanism has been 100 specified in [I-D.ietf-tls-dtls-connection-id] for DTLS 1.2 and in 101 [I-D.ietf-tls-dtls13] for DTLS 1.3. 103 Section 6 of [I-D.ietf-tls-dtls-connection-id] describes how the use 104 of CID increases the attack surface by providing both on-path and 105 off-path attackers an opportunity for (D)DoS. It then goes on 106 describing the steps a DTLS principal must take when a record with a 107 CID is received that has a source address (and/or port) different 108 from the one currently associated with the DTLS connection. However, 109 the actual mechanism for ensuring that the new peer address is 110 willing to receive and process DTLS records is left open. This 111 document standardizes a return routability check (RRC) as part of the 112 DTLS protocol itself. 114 The return routability check is performed by the receiving peer 115 before the CID-to-IP address/port binding is updated in that peer's 116 session state database. This is done in order to provide more 117 confidence to the receiving peer that the sending peer is reachable 118 at the indicated address and port. 120 Note however that, irrespective of CID, if RRC has been successfully 121 negotiated by the peers, path validation can be used at any time by 122 either endpoint. For instance, an endpoint might use RRC to check 123 that a peer is still in possession of its address after a period of 124 quiescence. 126 2. Conventions and Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in 131 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 132 capitals, as shown here. 134 This document assumes familiarity with the CID format and protocol 135 defined for DTLS 1.2 [I-D.ietf-tls-dtls-connection-id] and for DTLS 136 1.3 [I-D.ietf-tls-dtls13]. The presentation language used in this 137 document is described in Section 4 of [RFC8446]. 139 This document reuses the definition of "anti-amplification limit" 140 from [RFC9000] to mean three times the amount of data received from 141 an unvalidated address. This includes all DTLS records originating 142 from that source address, excluding discarded ones. 144 3. RRC Extension 146 The use of RRC is negotiated via the "rrc" DTLS-only extension. On 147 connecting, the client includes the "rrc" extension in its 148 ClientHello if it wishes to use RRC. If the server is capable of 149 meeting this requirement, it responds with a "rrc" extension in its 150 ServerHello. The "extension_type" value for this extension is TBD1 151 and the "extension_data" field of this extension is empty. The 152 client and server MUST NOT use RRC unless both sides have 153 successfully exchanged "rrc" extensions. 155 Note that the RRC extension applies to both DTLS 1.2 and DTLS 1.3. 157 4. The Return Routability Check Message 159 When a record with CID is received that has the source address of the 160 enclosing UDP datagram different from the one previously associated 161 with that CID, the receiver MUST NOT update its view of the peer's IP 162 address and port number with the source specified in the UDP datagram 163 before cryptographically validating the enclosed record(s) but 164 instead perform a return routability check. 166 enum { 167 invalid(0), 168 change_cipher_spec(20), 169 alert(21), 170 handshake(22), 171 application_data(23), 172 heartbeat(24), /* RFC 6520 */ 173 return_routability_check(TBD2), /* NEW */ 174 (255) 175 } ContentType; 177 uint64 Cookie; 179 enum { 180 path_challenge(0), 181 path_response(1), 182 reserved(2..255) 183 } rrc_msg_type; 185 struct { 186 rrc_msg_type msg_type; 187 select (return_routability_check.msg_type) { 188 case path_challenge: Cookie; 189 case path_response: Cookie; 190 }; 191 } return_routability_check; 192 The newly introduced "return_routability_check" message contains a 193 cookie. The cookie is a 8-byte field containing arbitrary data. 195 The "return_routability_check" message MUST be authenticated and 196 encrypted using the currently active security context. 198 5. Path Validation Procedure 200 The receiver that observes the peer's address or port update MUST 201 stop sending any buffered application data (or limit the data sent to 202 the unvalidated address to the anti-amplification limit) and initiate 203 the return routability check that proceeds as follows: 205 1. An unpredictable cookie is placed in a "return_routability_check" 206 message of type path_challenge; 208 2. The message is sent to the observed new address and a timer T 209 (see Section 5.3) is started; 211 3. The peer endpoint, after successfully verifying the received 212 "return_routability_check" message responds by echoing the cookie 213 value in a "return_routability_check" message of type 214 path_response; 216 4. When the initiator receives and verifies the 217 "return_routability_check" message contains the sent cookie, it 218 updates the peer address binding; 220 5. If T expires, or the address confirmation fails, the peer address 221 binding is not updated. 223 After this point, any pending send operation is resumed to the bound 224 peer address. 226 Section 5.1 and Section 5.2 contain the requirements for the 227 initiator and responder roles, broken down per protocol phase. 229 5.1. Path Challenge Requirements 231 - The initiator MAY send multiple "return_routability_check" 232 messages of type path_challenge to cater for packet loss on the 233 probed path. 235 o Each path_challenge SHOULD go into different transport packets. 236 (Note that the DTLS implementation may not have control over 237 the packetization done by the transport layer.) 239 o The transmission of subsequent path_challenge messages SHOULD 240 be paced to decrease the chance of loss. 242 o Each path_challenge message MUST contain random data. 244 - The initiator MAY use padding using the record padding mechanism 245 available in DTLS 1.3 (and in DTLS 1.2, when CID is enabled on the 246 sending direction) up to the anti-amplification limit to probe if 247 the path MTU (PMTU) for the new path is still acceptable. 249 5.2. Path Response Requirements 251 - The responder MUST NOT delay sending an elicited path_response 252 message. 254 - The responder MUST send exactly one path_response messages for 255 each received path_request. 257 - The responder MUST send the path_response on the network path 258 where the corresponding path_challenge has been received, so that 259 validation succeeds only if the path is functional in both 260 directions. 262 o The initiator MUST NOT enforce this behaviour 264 - The initiator MUST silently discard any invalid path_response it 265 receives. 267 Note that RRC does not cater for PMTU discovery on the reverse path. 268 If the responder wants to do PMTU discovery using RRC, it should 269 initiate a new path validation procedure. 271 5.3. Timer Choice 273 When setting T, implementations are cautioned that the new path could 274 have a longer round-trip time (RTT) than the original. 276 In settings where there is external information about the RTT of the 277 active path, implementations SHOULD use T = 3xRTT. 279 If an implementation has no way to obtain information regarding the 280 RTT of the active path, a value of 1s SHOULD be used. 282 Profiles for specific deployment environments - for example, 283 constrained networks [I-D.ietf-uta-tls13-iot-profile] - MAY specify a 284 different, more suitable value. 286 6. Example 288 The example TLS 1.3 handshake shown in Figure 1 shows a client and a 289 server negotiating the support for CID and for the RRC extension. 291 Client Server 293 Key ^ ClientHello 294 Exch | + key_share 295 | + signature_algorithms 296 | + rrc 297 v + connection_id=empty 298 --------> 299 ServerHello ^ Key 300 + key_share | Exch 301 + connection_id=100 | 302 + rrc v 303 {EncryptedExtensions} ^ Server 304 {CertificateRequest} v Params 305 {Certificate} ^ 306 {CertificateVerify} | Auth 307 <-------- {Finished} v 309 ^ {Certificate} 310 Auth | {CertificateVerify} 311 v {Finished} --------> 312 [Application Data] <-------> [Application Data] 314 + Indicates noteworthy extensions sent in the 315 previously noted message. 317 * Indicates optional or situation-dependent 318 messages/extensions that are not always sent. 320 {} Indicates messages protected using keys 321 derived from a [sender]_handshake_traffic_secret. 323 [] Indicates messages protected using keys 324 derived from [sender]_application_traffic_secret_N. 326 Figure 1: Message Flow for Full TLS Handshake 328 Once a connection has been established the client and the server 329 exchange application payloads protected by DTLS with an unilaterally 330 used CIDs. In our case, the client is requested to use CID 100 for 331 records sent to the server. 333 At some point in the communication interaction the IP address used by 334 the client changes and, thanks to the CID usage, the security context 335 to interpret the record is successfully located by the server. 336 However, the server wants to test the reachability of the client at 337 his new IP address. 339 Client Server 340 ------ ------ 342 Application Data ========> 343 344 Src-IP=A 345 Dst-IP=Z 346 <======== Application Data 347 Src-IP=Z 348 Dst-IP=A 350 <<------------->> 351 << Some >> 352 << Time >> 353 << Later >> 354 <<------------->> 356 Application Data ========> 357 358 Src-IP=B 359 Dst-IP=Z 361 <<< Unverified IP 362 Address B >> 364 <-------- Return Routability Check 365 path_challenge(cookie) 366 Src-IP=Z 367 Dst-IP=B 369 Return Routability Check --------> 370 path_response(cookie) 371 Src-IP=B 372 Dst-IP=Z 374 <<< IP Address B 375 Verified >> 377 <======== Application Data 378 Src-IP=Z 379 Dst-IP=B 381 Figure 2: Return Routability Example 383 7. Security and Privacy Considerations 385 Note that the return routability checks do not protect against 386 flooding of third-parties if the attacker is on-path, as the attacker 387 can redirect the return routability checks to the real peer (even if 388 those datagrams are cryptographically authenticated). On-path 389 adversaries can, in general, pose a harm to connectivity. 391 8. IANA Considerations 393 IANA is requested to allocate an entry to the TLS "ContentType" 394 registry, for the "return_routability_check(TBD2)" defined in this 395 document. The "return_routability_check" content type is only 396 applicable to DTLS 1.2 and 1.3. 398 IANA is requested to allocate the extension code point (TBD1) for the 399 "rrc" extension to the "TLS ExtensionType Values" registry as 400 described in Table 1. 402 +-------+-------------+-------+-----------+-------------+-----------+ 403 | Value | Extension | TLS | DTLS-Only | Recommended | Reference | 404 | | Name | 1.3 | | | | 405 +-------+-------------+-------+-----------+-------------+-----------+ 406 | TBD1 | rrc | CH, | Y | N | RFC-THIS | 407 | | | SH | | | | 408 +-------+-------------+-------+-----------+-------------+-----------+ 410 Table 1: rrc entry in the TLS ExtensionType Values registry 412 9. Open Issues 414 Issues against this document are tracked at https://github.com/tlswg/ 415 dtls-rrc/issues 417 10. Acknowledgments 419 We would like to thank Achim Kraus, Hanno Becker, Hanno Boeck, Manuel 420 Pegourie-Gonnard, Mohit Sahni and Rich Salz for their input to this 421 document. 423 11. References 425 11.1. Normative References 427 [I-D.ietf-tls-dtls-connection-id] 428 RTFM, Inc., Arm Limited, Arm Limited, and Bosch.IO GmbH, 429 "Connection Identifiers for DTLS 1.2", draft-ietf-tls- 430 dtls-connection-id-13 (work in progress), June 2021. 432 [I-D.ietf-tls-dtls13] 433 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 434 Datagram Transport Layer Security (DTLS) Protocol Version 435 1.3", draft-ietf-tls-dtls13-43 (work in progress), April 436 2021. 438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 439 Requirement Levels", BCP 14, RFC 2119, 440 DOI 10.17487/RFC2119, March 1997, 441 . 443 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 444 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 445 May 2017, . 447 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 448 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 449 . 451 11.2. Informative References 453 [I-D.ietf-uta-tls13-iot-profile] 454 Arm Limited and Arm Limited, "TLS/DTLS 1.3 Profiles for 455 the Internet of Things", draft-ietf-uta-tls13-iot- 456 profile-03 (work in progress), October 2021. 458 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 459 Multiplexed and Secure Transport", RFC 9000, 460 DOI 10.17487/RFC9000, May 2021, 461 . 463 Appendix A. History 465 [[CREF1: RFC EDITOR: PLEASE REMOVE THIS SECTION]] 467 draft-ietf-tls-dtls-rrc-02 469 - Undo the TLS flags extension for negotiating RRC, use a new 470 extension type 472 draft-ietf-tls-dtls-rrc-01 474 - Use the TLS flags extension for negotiating RRC 476 - Enhanced IANA consideration section 478 - Expanded example section 480 - Revamp message layout: 482 o Use 8-byte fixed size cookies 484 o Explicitly separate path challenge from response 486 draft-ietf-tls-dtls-rrc-00 488 - Draft name changed after WG adoption 490 draft-tschofenig-tls-dtls-rrc-01 492 - Removed text that overlapped with draft-ietf-tls-dtls-connection- 493 id 495 draft-tschofenig-tls-dtls-rrc-00 497 - Initial version 499 Authors' Addresses 501 Hannes Tschofenig (editor) 502 Arm Limited 504 EMail: hannes.tschofenig@arm.com 506 Thomas Fossati (editor) 507 Arm Limited 509 EMail: thomas.fossati@arm.com