idnits 2.17.00 (12 Aug 2021) /tmp/idnits958/draft-ietf-tls-dtls-rrc-05.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: ---------------------------------------------------------------------------- == Line 534 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 (7 March 2022) is 68 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: draft-ietf-tls-dtls-connection-id has been published as RFC 9146 == Outdated reference: draft-ietf-tls-dtls13 has been published as RFC 9147 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 4 Updates: 6347 (if approved) Arm Limited 5 Intended status: Standards Track 7 March 2022 6 Expires: 8 September 2022 8 Return Routability Check for DTLS 1.2 and DTLS 1.3 9 draft-ietf-tls-dtls-rrc-05 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 Discussion Venues 19 This note is to be removed before publishing as an RFC. 21 Discussion of this document takes place on the Transport Layer 22 Security Working Group mailing list (tls@ietf.org), which is archived 23 at https://mailarchive.ietf.org/arch/browse/tls/. 25 Source for this draft and an issue tracker can be found at 26 https://github.com/tlswg/dtls-rrc. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 8 September 2022. 45 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 75 3. RRC Extension . . . . . . . . . . . . . . . . . . . . . . . . 4 76 4. The Return Routability Check Message . . . . . . . . . . . . 4 77 5. Off-Path Packet Forwarding . . . . . . . . . . . . . . . . . 5 78 6. Path Validation Procedure . . . . . . . . . . . . . . . . . . 9 79 7. Enhanced Path Validation Procedure . . . . . . . . . . . . . 10 80 7.1. Path Challenge Requirements . . . . . . . . . . . . . . 11 81 7.2. Path Response/Delete Requirements . . . . . . . . . . . . 12 82 7.3. Timer Choice . . . . . . . . . . . . . . . . . . . . . . 12 83 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 9. Security and Privacy Considerations . . . . . . . . . . . . . 15 85 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 86 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 88 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 13.1. Normative References . . . . . . . . . . . . . . . . . . 15 90 13.2. Informative References . . . . . . . . . . . . . . . . . 16 91 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 16 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 94 1. Introduction 96 In "classical" DTLS, selecting a security context of an incoming DTLS 97 record is accomplished with the help of the 5-tuple, i.e. source IP 98 address, source port, transport protocol, destination IP address, and 99 destination port. Changes to this 5 tuple can happen for a variety 100 reasons over the lifetime of the DTLS session. In the IoT context, 101 NAT rebinding is common with sleepy devices. Other examples include 102 end host mobility and multi-homing. Without CID, if the source IP 103 address and/or source port changes during the lifetime of an ongoing 104 DTLS session then the receiver will be unable to locate the correct 105 security context. As a result, the DTLS handshake has to be re-run. 106 Of course, it is not necessary to re-run the full handshake if 107 session resumption is supported and negotiated. 109 A CID is an identifier carried in the record layer header of a DTLS 110 datagram that gives the receiver additional information for selecting 111 the appropriate security context. The CID mechanism has been 112 specified in [I-D.ietf-tls-dtls-connection-id] for DTLS 1.2 and in 113 [I-D.ietf-tls-dtls13] for DTLS 1.3. 115 Section 6 of [I-D.ietf-tls-dtls-connection-id] describes how the use 116 of CID increases the attack surface by providing both on-path and 117 off-path attackers an opportunity for (D)DoS. It then goes on 118 describing the steps a DTLS principal must take when a record with a 119 CID is received that has a source address (and/or port) different 120 from the one currently associated with the DTLS connection. However, 121 the actual mechanism for ensuring that the new peer address is 122 willing to receive and process DTLS records is left open. This 123 document standardizes a return routability check (RRC) as part of the 124 DTLS protocol itself. 126 The return routability check is performed by the receiving peer 127 before the CID-to-IP address/port binding is updated in that peer's 128 session state database. This is done in order to provide more 129 confidence to the receiving peer that the sending peer is reachable 130 at the indicated address and port. 132 Note however that, irrespective of CID, if RRC has been successfully 133 negotiated by the peers, path validation can be used at any time by 134 either endpoint. For instance, an endpoint might use RRC to check 135 that a peer is still in possession of its address after a period of 136 quiescence. 138 2. Conventions and Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in 143 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 This document assumes familiarity with the CID format and protocol 147 defined for DTLS 1.2 [I-D.ietf-tls-dtls-connection-id] and for DTLS 148 1.3 [I-D.ietf-tls-dtls13]. The presentation language used in this 149 document is described in Section 4 of [RFC8446]. 151 This document reuses the definition of "anti-amplification limit" 152 from [RFC9000] to mean three times the amount of data received from 153 an unvalidated address. This includes all DTLS records originating 154 from that source address, excluding discarded ones. 156 3. RRC Extension 158 The use of RRC is negotiated via the rrc DTLS-only extension. On 159 connecting, the client includes the rrc extension in its ClientHello 160 if it wishes to use RRC. If the server is capable of meeting this 161 requirement, it responds with a rrc extension in its ServerHello. 162 The extension_type value for this extension is TBD1 and the 163 extension_data field of this extension is empty. The client and 164 server MUST NOT use RRC unless both sides have successfully exchanged 165 rrc extensions. 167 Note that the RRC extension applies to both DTLS 1.2 and DTLS 1.3. 169 4. The Return Routability Check Message 171 When a record with CID is received that has the source address of the 172 enclosing UDP datagram different from the one previously associated 173 with that CID, the receiver MUST NOT update its view of the peer's IP 174 address and port number with the source specified in the UDP datagram 175 before cryptographically validating the enclosed record(s) but 176 instead perform a return routability check. 178 enum { 179 invalid(0), 180 change_cipher_spec(20), 181 alert(21), 182 handshake(22), 183 application_data(23), 184 heartbeat(24), /* RFC 6520 */ 185 return_routability_check(TBD2), /* NEW */ 186 (255) 187 } ContentType; 189 uint64 Cookie; 191 enum { 192 path_challenge(0), 193 path_response(1), 194 path_delete(2), 195 reserved(2..255) 196 } rrc_msg_type; 198 struct { 199 rrc_msg_type msg_type; 200 select (return_routability_check.msg_type) { 201 case path_challenge: Cookie; 202 case path_response: Cookie; 203 case path_delete: Cookie; 204 }; 205 } return_routability_check; 207 The cookie is a 8-byte field containing arbitrary data. 209 The return_routability_check message MUST be authenticated and 210 encrypted using the currently active security context. 212 5. Off-Path Packet Forwarding 214 An off-path attacker that can observe packets might forward copies of 215 genuine packets to endpoints. If the copied packet arrives before 216 the genuine packet, this will appear as a NAT rebinding. Any genuine 217 packet will be discarded as a duplicate. If the attacker is able to 218 continue forwarding packets, it might be able to cause migration to a 219 path via the attacker. This places the attacker on-path, giving it 220 the ability to observe or drop all subsequent packets. 222 This style of attack relies on the attacker using a path that has 223 approximately the same characteristics as the direct path between 224 endpoints. The attack is more reliable if relatively few packets are 225 sent or if packet loss coincides with the attempted attack. 227 A data packet received on the original path that increases the 228 maximum received packet number will cause the endpoint to move back 229 to that path. Eliciting packets on this path increases the 230 likelihood that the attack is unsuccessful. 232 Figure 1 demonstrates the case where a receiver receives a packet 233 with a new source IP address and/or new port number. The receiver 234 needs to determine whether this path change is caused by an attacker 235 and will send a RRC message of type path_challenge (RRC-1) on the old 236 path. 238 new +--------+ old 239 path | | path 240 +----->|Receiver|<-----+ 241 | | | | 242 | +--------+ | 243 | | 244 | | 245 | | 246 | | 247 | | 248 +----------+ | 249 | Attacker?| | 250 +----------+ | 251 | | 252 | | 253 | | 254 | +--------+ | 255 | | | | 256 +------| Sender |------+ 257 | | 258 +--------+ 260 Figure 1: Off-Path Packet Forwarding Scenario 262 Three cases need to be considered: 264 Case 1: The old path is dead, which leads to a timeout of RRC-1. 266 As shown in Figure 2, a RRC message of type path_challenge (RRC-2) 267 needs to be sent on the new path. In this situation the switch to 268 the new path is considered legitimate. The sender will reply with 269 RRC-3 containing a path_response on the new path. 271 ...................>+--------+ 272 . ********| |******** 273 . *+----->|Receiver|<-----+* 274 . *| new | | old |* 275 . RRC-2 *| path +--------+ path |* RRC-1 276 . with *| |* with 277 . path- *| |* path- 278 . challenge *| |* challenge 279 . *| |* 280 . *| |* 281 . +----------+ |* 282 . | Attacker | |* 283 . +----------+ |* 284 . *| |v 285 . *| |timeout 286 . *| | 287 .RRC-3 *| +--------+ | 288 .with *| | | | 289 .path- *+------| Sender |------+ 290 .response *******>| | 291 ....................+--------+ 293 Figure 2: Old path is dead 295 Case 2: The old path is alive but not preferred. 297 This case is shown in Figure 3 whereby the sender replies with a 298 RRC-2 path_delete message on the old path. This triggers the 299 receiver to send RRC-3 with a path-challenge along the new path. The 300 sender will reply with RRC-4 containing a path_response along the new 301 path. 303 ...................>+--------+<.................... 304 . ********| |******** . 305 . *+----->|Receiver|<-----+* . 306 . *| new | | old |* . 307 . RRC-3 *| path +--------+ path |* RRC-1 . 308 . with *| |* with . 309 . path- *| |* path- . 310 . challenge *| |* challenge . 311 . *| |* . 312 . *| |* . 313 . +----------+ |* . 314 . | Attacker | |* . 315 . +----------+ |* . 316 . *| |* . 317 . *| |* . 318 . *| |* . 319 .RRC-4 *| +--------+ |* RRC-2. 320 .with *| | | |* with. 321 .path- *+------| Sender |------+* path-. 322 .response *******>| |<******* delete. 323 ....................+--------+..................... 325 Figure 3: Old path is not preferred 327 Case 3: The old path is alive and preferred. 329 This is most likely the result of an attacker. The sender replies 330 with RRC-2 containing a path_response along the old path. The 331 interaction is shown in Figure 4. This results in the connection 332 being migrated back to the old path. 334 +--------+<.................... 335 | |******** . 336 +----->|Receiver|<-----+* . 337 | new | | old |* . 338 | path +--------+ path |* RRC-1 . 339 | |* with . 340 | |* path- . 341 | |* challenge . 342 | |* . 343 | |* . 344 +----------+ |* . 345 | Attacker | |* . 346 +----------+ |* . 347 | |* . 348 | |* . 349 | |* . 350 | +--------+ |* RRC-2. 351 | | | |* with. 352 +------| Sender |------+* path-. 353 | |<******* response. 354 +--------+..................... 356 Figure 4: Old path is preferred 358 Note that this defense is imperfect, but this is not considered a 359 serious problem. If the path via the attack is reliably faster than 360 the old path despite multiple attempts to use that old path, it is 361 not possible to distinguish between an attack and an improvement in 362 routing. 364 An endpoint could also use heuristics to improve detection of this 365 style of attack. For instance, NAT rebinding is improbable if 366 packets were recently received on the old path; similarly, rebinding 367 is rare on IPv6 paths. Endpoints can also look for duplicated 368 packets. Conversely, a change in connection ID is more likely to 369 indicate an intentional migration rather than an attack. Note, 370 however, changes in connection IDs are only supported in DTLS 1.3 but 371 not in DTLS 1.2. 373 6. Path Validation Procedure 375 Note: This algorithm does not take the Section 5 scenario into 376 account. 378 The receiver that observes the peer's address or port update MUST 379 stop sending any buffered application data (or limit the data sent to 380 the unvalidated address to the anti-amplification limit) and initiate 381 the return routability check that proceeds as follows: 383 1. The receiver creates a return_routability_check message of type 384 path_challenge and places the unpredictable cookie into the 385 message. 387 2. The message is sent to the observed new address and a timer T 388 (see Section 7.3) is started. 390 3. The peer endpoint, after successfully verifying the received 391 return_routability_check message responds by echoing the cookie 392 value in a return_routability_check message of type 393 path_response. 395 4. When the initiator receives and verifies the 396 return_routability_check message contains the sent cookie, it 397 updates the peer address binding. 399 5. If T expires, or the address confirmation fails, the peer address 400 binding is not updated. 402 After this point, any pending send operation is resumed to the bound 403 peer address. 405 Section 7.1 and Section 7.2 contain the requirements for the 406 initiator and responder roles, broken down per protocol phase. 408 7. Enhanced Path Validation Procedure 410 Note: This algorithm also takes the Section 5 scenario into account. 412 The receiver that observes the peer's address or port update MUST 413 stop sending any buffered application data (or limit the data sent to 414 the unvalidated address to the anti-amplification limit) and initiate 415 the return routability check that proceeds as follows: 417 1. The receiver creates a return_routability_check message of type 418 path_challenge and places the unpredictable cookie into the 419 message. 421 2. The message is sent to the previously valid address, which 422 corresponds to the old path. Additionally, a timer T, see 423 Section 7.3, is started. 425 3. The peer endpoint verifies the received return_routability_check 426 message. The action to be taken depends on the preference of the 427 path through which the message was received: 429 * If the path through which the message was received is 430 preferred, a return_routability_check message of type 431 path_response MUST be returned. 433 * If the path through which the message was received is not 434 preferred, a return_routability_check message of type 435 path_delete MUST be returned. In either case, the peer 436 endpoint echoes the cookie value in the response. 438 4. The initiator receives and verifies that the 439 return_routability_check message contains the previously sent 440 cookie. The actions taken by the initiator differ based on the 441 received message: 443 * When a return_routability_check message of type path_response 444 was received, the initiator MUST continue using the previously 445 valid address, i.e. no switch to the new path takes place and 446 the peer address binding is not updated. 448 * When a return_routability_check message of type path_delete 449 was received, the initiator MUST perform a return routability 450 check on the observed new address, as described in Section 6. 452 5. If T expires, or the address confirmation fails, the peer address 453 binding is not updated. In this case, the initiator MUST perform 454 a return routability check on the observed new address, as 455 described in Section 6. 457 After the path validation procedure is completed, any pending send 458 operation is resumed to the bound peer address. 460 Section 7.1 and Section 7.2 contain the requirements for the 461 initiator and responder roles, broken down per protocol phase. 463 7.1. Path Challenge Requirements 465 * The initiator MAY send multiple return_routability_check messages 466 of type path_challenge to cater for packet loss on the probed 467 path. 469 - Each path_challenge SHOULD go into different transport packets. 470 (Note that the DTLS implementation may not have control over 471 the packetization done by the transport layer.) 473 - The transmission of subsequent path_challenge messages SHOULD 474 be paced to decrease the chance of loss. 476 - Each path_challenge message MUST contain random data. 478 * The initiator MAY use padding using the record padding mechanism 479 available in DTLS 1.3 (and in DTLS 1.2, when CID is enabled on the 480 sending direction) up to the anti-amplification limit to probe if 481 the path MTU (PMTU) for the new path is still acceptable. 483 7.2. Path Response/Delete Requirements 485 * The responder MUST NOT delay sending an elicited path_response or 486 path_delete messages. 488 * The responder MUST send exactly one path_response or path_delete 489 message for each received path_challenge. 491 * The responder MUST send the path_response or the path_delete on 492 the path where the corresponding path_challenge has been received, 493 so that validation succeeds only if the path is functional in both 494 directions. The initiator MUST NOT enforce this behaviour. 496 * The initiator MUST silently discard any invalid path_response it 497 receives. 499 Note that RRC does not cater for PMTU discovery on the reverse path. 500 If the responder wants to do PMTU discovery using RRC, it should 501 initiate a new path validation procedure. 503 7.3. Timer Choice 505 When setting T, implementations are cautioned that the new path could 506 have a longer round-trip time (RTT) than the original. 508 In settings where there is external information about the RTT of the 509 active path, implementations SHOULD use T = 3xRTT. 511 If an implementation has no way to obtain information regarding the 512 RTT of the active path, a value of 1s SHOULD be used. 514 Profiles for specific deployment environments -- for example, 515 constrained networks [I-D.ietf-uta-tls13-iot-profile] -- MAY specify 516 a different, more suitable value. 518 8. Example 520 The example TLS 1.3 handshake shown in Figure 5 shows a client and a 521 server negotiating the support for CID and for the RRC extension. 523 Client Server 525 Key ^ ClientHello 526 Exch | + key_share 527 | + signature_algorithms 528 | + rrc 529 v + connection_id=empty 530 --------> 531 ServerHello ^ Key 532 + key_share | Exch 533 + connection_id=100 | 534 + rrc v 535 {EncryptedExtensions} ^ Server 536 {CertificateRequest} v Params 537 {Certificate} ^ 538 {CertificateVerify} | Auth 539 <-------- {Finished} v 541 ^ {Certificate} 542 Auth | {CertificateVerify} 543 v {Finished} --------> 544 [Application Data] <-------> [Application Data] 546 + Indicates noteworthy extensions sent in the 547 previously noted message. 549 * Indicates optional or situation-dependent 550 messages/extensions that are not always sent. 552 {} Indicates messages protected using keys 553 derived from a [sender]_handshake_traffic_secret. 555 [] Indicates messages protected using keys 556 derived from [sender]_application_traffic_secret_N. 558 Figure 5: Message Flow for Full TLS Handshake 560 Once a connection has been established the client and the server 561 exchange application payloads protected by DTLS with an unilaterally 562 used CIDs. In our case, the client is requested to use CID 100 for 563 records sent to the server. 565 At some point in the communication interaction the IP address used by 566 the client changes and, thanks to the CID usage, the security context 567 to interpret the record is successfully located by the server. 568 However, the server wants to test the reachability of the client at 569 his new IP address. 571 Client Server 572 ------ ------ 574 Application Data ========> 575 576 Src-IP=A 577 Dst-IP=Z 578 <======== Application Data 579 Src-IP=Z 580 Dst-IP=A 582 <<------------->> 583 << Some >> 584 << Time >> 585 << Later >> 586 <<------------->> 588 Application Data ========> 589 590 Src-IP=B 591 Dst-IP=Z 593 <<< Unverified IP 594 Address B >> 596 <-------- Return Routability Check 597 path_challenge(cookie) 598 Src-IP=Z 599 Dst-IP=B 601 Return Routability Check --------> 602 path_response(cookie) 603 Src-IP=B 604 Dst-IP=Z 606 <<< IP Address B 607 Verified >> 609 <======== Application Data 610 Src-IP=Z 611 Dst-IP=B 613 Figure 6: Return Routability Example 615 9. Security and Privacy Considerations 617 Note that the return routability checks do not protect against 618 flooding of third-parties if the attacker is on-path, as the attacker 619 can redirect the return routability checks to the real peer (even if 620 those datagrams are cryptographically authenticated). On-path 621 adversaries can, in general, pose a harm to connectivity. 623 10. IANA Considerations 625 IANA is requested to allocate an entry to the TLS ContentType 626 registry, for the return_routability_check(TBD2) message defined in 627 this document. The return_routability_check content type is only 628 applicable to DTLS 1.2 and 1.3. 630 IANA is requested to allocate the extension code point (TBD1) for the 631 rrc extension to the TLS ExtensionType Values registry as described 632 in Table 1. 634 +=======+===========+=====+===========+=============+===========+ 635 | Value | Extension | TLS | DTLS-Only | Recommended | Reference | 636 | | Name | 1.3 | | | | 637 +=======+===========+=====+===========+=============+===========+ 638 | TBD1 | rrc | CH, | Y | N | RFC-THIS | 639 | | | SH | | | | 640 +-------+-----------+-----+-----------+-------------+-----------+ 642 Table 1: rrc entry in the TLS ExtensionType Values registry 644 11. Open Issues 646 Issues against this document are tracked at https://github.com/tlswg/ 647 dtls-rrc/issues 649 12. Acknowledgments 651 We would like to thank Achim Kraus, Hanno Becker, Hanno Boeck, Manuel 652 Pegourie-Gonnard, Mohit Sahni and Rich Salz for their input to this 653 document. 655 13. References 657 13.1. Normative References 659 [I-D.ietf-tls-dtls-connection-id] 660 Rescorla, E., Tschofenig, H., Fossati, T., and A. Kraus, 661 "Connection Identifiers for DTLS 1.2", Work in Progress, 662 Internet-Draft, draft-ietf-tls-dtls-connection-id-13, 22 663 June 2021, . 666 [I-D.ietf-tls-dtls13] 667 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 668 Datagram Transport Layer Security (DTLS) Protocol Version 669 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 670 dtls13-43, 30 April 2021, 671 . 674 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 675 Requirement Levels", BCP 14, RFC 2119, 676 DOI 10.17487/RFC2119, March 1997, 677 . 679 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 680 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 681 May 2017, . 683 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 684 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 685 . 687 13.2. Informative References 689 [I-D.ietf-uta-tls13-iot-profile] 690 Tschofenig, H. and T. Fossati, "TLS/DTLS 1.3 Profiles for 691 the Internet of Things", Work in Progress, Internet-Draft, 692 draft-ietf-uta-tls13-iot-profile-04, 7 March 2022, 693 . 696 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 697 Multiplexed and Secure Transport", RFC 9000, 698 DOI 10.17487/RFC9000, May 2021, 699 . 701 Appendix A. History 703 // RFC EDITOR: PLEASE REMOVE THIS SECTION 705 draft-ietf-tls-dtls-rrc-05 706 * Added text about off-path packet forwarding 708 draft-ietf-tls-dtls-rrc-04 710 * Re-submitted draft to fix references 712 draft-ietf-tls-dtls-rrc-03 714 * Added details for challenge-response exchange 716 draft-ietf-tls-dtls-rrc-02 718 * Undo the TLS flags extension for negotiating RRC, use a new 719 extension type 721 draft-ietf-tls-dtls-rrc-01 723 * Use the TLS flags extension for negotiating RRC 725 * Enhanced IANA consideration section 727 * Expanded example section 729 * Revamp message layout: 731 - Use 8-byte fixed size cookies 733 - Explicitly separate path challenge from response 735 draft-ietf-tls-dtls-rrc-00 737 * Draft name changed after WG adoption 739 draft-tschofenig-tls-dtls-rrc-01 741 * Removed text that overlapped with draft-ietf-tls-dtls-connection- 742 id 744 draft-tschofenig-tls-dtls-rrc-00 746 * Initial version 748 Authors' Addresses 750 Hannes Tschofenig (editor) 751 Arm Limited 752 Email: hannes.tschofenig@arm.com 753 Thomas Fossati 754 Arm Limited 755 Email: thomas.fossati@arm.com