idnits 2.17.1 draft-ietf-mmusic-dtls-sdp-21.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5763, updated by this document, for RFC5378 checks: 2007-11-12) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 12, 2017) is 2595 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) == Missing Reference: 'RFCXXXX' is mentioned on line 874, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-13) exists of draft-ietf-mmusic-4572-update-12 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 4572 (Obsoleted by RFC 8122) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-20) exists of draft-ietf-ice-rfc5245bis-08 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-16 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-36 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Updates: 5763,7345 (if approved) R. Shpount 5 Intended status: Standards Track TurboBridge 6 Expires: September 13, 2017 March 12, 2017 8 Using the SDP Offer/Answer Mechanism for DTLS 9 draft-ietf-mmusic-dtls-sdp-21.txt 11 Abstract 13 This document defines the SDP offer/answer procedures for negotiating 14 and establishing a DTLS association. The document also defines the 15 criteria for when a new DTLS association must be established. The 16 document updates RFC 5763 and RFC 7345, by replacing common SDP 17 offer/answer procedures with a reference to this specification. 19 This document defines a new SDP media-level attribute, 'dtls-id'. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 13, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Establishing a new DTLS Association . . . . . . . . . . . . . 3 58 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.2. Change of Local Transport Parameters . . . . . . . . . . 4 60 3.3. Change of ICE ufrag value . . . . . . . . . . . . . . . . 4 61 4. SDP dtls-id Attribute . . . . . . . . . . . . . . . . . . . . 4 62 5. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 6 63 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5.2. Generating the Initial SDP Offer . . . . . . . . . . . . 8 65 5.3. Generating the Answer . . . . . . . . . . . . . . . . . . 8 66 5.4. Offerer Processing of the SDP Answer . . . . . . . . . . 9 67 5.5. Modifying the Session . . . . . . . . . . . . . . . . . . 9 68 6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 7. Transport Protocol Considerations . . . . . . . . . . . . . . 11 70 7.1. Transport Re-Usage . . . . . . . . . . . . . . . . . . . 11 71 8. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 9. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 9.2. Update to RFC 5763 . . . . . . . . . . . . . . . . . . . 11 75 9.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 16 76 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 77 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 78 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 79 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 20 80 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 81 14.1. Normative References . . . . . . . . . . . . . . . . . . 24 82 14.2. Informative References . . . . . . . . . . . . . . . . . 25 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 85 1. Introduction 87 [RFC5763] defines SDP offer/answer procedures for SRTP-DTLS. 88 [RFC7345] defines SDP offer/answer procedures for UDPTL-DTLS. This 89 specification defines general offer/answer procedures for DTLS, based 90 on the procedures in [RFC5763]. Other specifications, defining 91 specific DTLS usages, can then reference this specification, in order 92 to ensure that the DTLS aspects are common among all usages. Having 93 common procedures is essential when multiple usages share the same 94 DTLS association [I-D.ietf-mmusic-sdp-bundle-negotiation]. The 95 document updates [RFC5763] and [RFC7345], by replacing common SDP 96 offer/answer procedures with a reference to this specification. 98 As defined in [RFC5763], a new DTLS association MUST be established 99 when transport parameters are changed. Transport parameter change is 100 not well defined when Interactive Connectivity Establishment (ICE) 101 [I-D.ietf-ice-rfc5245bis] is used. One possible way to determine a 102 transport change is based on ufrag change, but the ufrag value is 103 changed both when ICE is negotiated and when ICE restart 104 [I-D.ietf-ice-rfc5245bis] occurs. These events do not always require 105 a new DTLS association to be established, but currently there is no 106 way to explicitly indicate in an SDP offer or answer whether a new 107 DTLS association is required. To solve that problem, this document 108 defines a new SDP attribute, 'dtls-id'. The pair of SDP 'dtls-id' 109 attribute values (the attribute values of the offerer and the 110 answerer) uniquely identifies the DTLS association. Providing a new 111 value of the 'dtls-id' attribute in an SDP offer or answers can be 112 used to indicate whether a new DTLS association is to be established. 114 2. Conventions 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 3. Establishing a new DTLS Association 122 3.1. General 124 A new DTLS association MUST be established after a successful SDP 125 offer/answer exchange in the following cases: 127 o The negotiated DTLS setup roles change; or 129 o One or more fingerprint values are modified, added or removed in 130 either an SDP offer or answer; or 132 o The intent to establish a new DTLS association is explicitly 133 signaled by changing the value of the SDP 'dtls-id' attribute 134 defined in this document; 136 NOTE: The first two items above are based on the procedures in 137 [RFC5763]. This specification adds the support for explicit 138 signaling using the SDP 'dtls-id' attribute. 140 A new DTLS association can only be established as a result of the 141 successful SDP offer/answer exchange. Whenever an entity determines 142 that a new DTLS association is required, the entity MUST initiate an 143 SDP offer/answer exchange, following the procedures in Section 5. 145 The sections below describe typical cases where a new DTLS 146 association needs to be established. 148 3.2. Change of Local Transport Parameters 150 If an endpoint modifies its local transport parameters (address and/ 151 or port), and if the modification requires a new DTLS association, 152 the endpoint MUST change its local SDP 'dtls-id' attribute value (see 153 Section 4). 155 If the underlying transport explicitly prohibits a DTLS association 156 to span multiple transports, and if the transport is changed, the 157 endpoint MUST change its local SDP 'dtls-id' attribute value (see 158 Section 4). An example of such a case is when DTLS is carried over 159 SCTP, as described in [RFC6083]. 161 3.3. Change of ICE ufrag value 163 If an endpoint uses ICE, and modifies a local ufrag value, and if the 164 modification requires a new DTLS association, the endpoint MUST 165 change its local SDP 'dtls-id' attribute value (see Section 4). 167 4. SDP dtls-id Attribute 169 The pair of SDP 'dtls-id' attribute values (the attribute values of 170 the offerer and the answerer) uniquely identifies the DTLS 171 association. 173 Name: dtls-id 175 Value: dtls-id-value 177 Usage Level: media 179 Charset Dependent: no 181 Default Value: N/A 183 Syntax: 185 dtls-id-value = 20*255(dtls-id-char) 186 dtls-id-char = ALPHA / DIGIT / "+" / "/" / "-" / "_" 188 190 Example: 192 a=dtls-id:abc3de65cddef001be82 194 Every time an endpoint requests to establish a new DTLS association, 195 the endpoint MUST generate a new local 'dtls-id' attribute value. A 196 non-changed local 'dtls-id' attribute value, in combination with non- 197 changed fingerprints, indicates that the endpoint intends to reuse 198 the existing DTLS association. 200 The 'dtls-id' attribute value MUST be generated using a cryptographic 201 random function and include at least 120 bits of randomness. 203 No default value is defined for the SDP 'dtls-id' attribute. 204 Implementations that wish to use the attribute MUST explicitly 205 include it in SDP offers and answers. If an offer or answer does not 206 contain a 'dtls-id' attribute (this could happen if the offerer or 207 answerer represents an existing implementation that has not been 208 updated to support the 'dtls-id' attribute), the offer or answer MUST 209 be treated as if no 'dtls-id' attribute is included. Unless there is 210 another mechanism to explicitly indicate that a new DTLS association 211 is to be established, a modification of one or more of the following 212 characteristics MUST be treated as an indication that an endpoint 213 wants to establish a new DTLS association: 215 o DTLS setup role; or 217 o fingerprint set; or 218 o local transport parameters; or 220 o ICE ufrag value 222 The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'dtls- 223 id' attribute is 'IDENTICAL', which means that the attribute value 224 must be identical across all media descriptions being multiplexed 225 [I-D.ietf-mmusic-sdp-bundle-negotiation]. 227 For RTP-based media, the 'dtls-id' attribute applies to the whole 228 associated media description. The attribute MUST NOT be defined per 229 source (using the SDP 'ssrc' attribute [RFC5576]). 231 The SDP offer/answer [RFC3264] procedures associated with the 232 attribute are defined in Section 5. 234 5. SDP Offer/Answer Procedures 236 5.1. General 238 This section defines the generic SDP offer/answer procedures for 239 negotiating a DTLS association. Additional procedures (e.g., 240 regarding usage of specific SDP attributes etc.) for individual DTLS 241 usages (e.g., SRTP-DTLS) are outside the scope of this specification, 242 and need to be specified in a usage specific specification. 244 NOTE: The procedures in this section are generalizations of 245 procedures first specified in SRTP-DTLS [RFC5763], with the addition 246 of usage of the SDP 'dtls-id' attribute. That document is herein 247 updated to make use of these new procedures. 249 The procedures in this section apply to an SDP media description 250 ("m=" line) associated with DTLS-protected media/data. 252 When an offerer or answerer indicates that it wants to establish a 253 new DTLS association, it needs to make sure that media packets in the 254 existing DTLS association and new DTLS association can be de- 255 multiplexed. In case of an ordered transport (e.g., SCTP) this can 256 be done simply by sending packets for the new DTLS association after 257 all packets for the existing DTLS association have been sent. In 258 case of an unordered transport, such as UDP, packets for the old DTLS 259 association can arrive after the answer SDP was received and after 260 the first packets for the new DTLS association were received. The 261 only way to de-multiplex packets belonging to the old and new DTLS 262 association is on the basis of transport 5-tuple. Because of this, 263 if an unordered transport is used for the DTLS association, a new 264 transport (3-tuple) MUST be allocated by at least one of the end 265 points so that DTLS packets can be de-multiplexed. 267 When an offerer needs to establish a new DTLS association, and if an 268 unordered transport (e.g., UDP) is used, the offerer MUST allocate a 269 new transport (3-tuple) for the offer in such a way that the offerer 270 can disambiguate any packets associated with the new DTLS association 271 from any packets associated with any other DTLS association. This 272 typically means using a local address and/or port, or a set of ICE 273 candidates (see Section 6), which were not recently used for any 274 other DTLS association. 276 When an answerer needs to establish a new DTLS association, if an 277 unordered transport is used, and if the offerer did not allocate a 278 new transport, the answerer MUST allocate a new transport for the 279 answer in such a way that it can disambiguate any packets associated 280 with the new DTLS association from any packets associated with any 281 other DTLS association. This typically means using a local address 282 and/or port, or a set of ICE candidates (see Section 6), which were 283 not recently used for any other DTLS association. 285 In order to negotiate a DTLS association, the following SDP 286 attributes are used: 288 o The SDP 'setup' attribute, defined in [RFC4145], is used to 289 negotiate the DTLS roles; 291 o The SDP 'fingerprint' attribute, defined in 292 [I-D.ietf-mmusic-4572-update], is used to provide one or more 293 fingerprint values; and 295 o The SDP 'dtls-id' attribute, defined in this specification, is 296 used to identity the DTLS association. 298 This specification does not define the usage of the SDP 'connection' 299 attribute [RFC4145] for negotiating a DTLS association. However, the 300 attribute MAY be used if the DTLS association is used together with 301 another protocol (e.g., SCTP or TCP) for which the usage of the 302 attribute has been defined. 304 Unlike for TCP and TLS connections, endpoints MUST NOT use the SDP 305 'setup' attribute 'holdconn' value when negotiating a DTLS 306 association. 308 Endpoints MUST support the cipher suites as defined in 309 [I-D.ietf-mmusic-4572-update]. 311 The certificate received during the DTLS handshake MUST match a 312 certificate fingerprints received in SDP 'fingerprint' attributes 313 according to the procedures defined in [I-D.ietf-mmusic-4572-update]. 314 If fingerprints do not match the hashed certificate, then an endpoint 315 MUST tear down the media session immediately (see 316 [I-D.ietf-mmusic-4572-update]). Note that it is permissible to wait 317 until the other side's fingerprint(s) has been received before 318 establishing the connection; however, this may have undesirable 319 latency effects. 321 SDP offerers and answerers might reuse certificates across multiple 322 DTLS associations, and provide identical fingerprint values for each 323 DTLS association. The combination of the SDP 'dtls-id' attribute 324 values of the SDP offerer and answerer identifies each individual 325 DTLS association. 327 5.2. Generating the Initial SDP Offer 329 When an offerer sends the initial offer, the offerer MUST insert an 330 SDP 'setup' attribute according to the procedures in [RFC4145], and 331 one or more SDP 'fingerprint' attributes according to the procedures 332 in [I-D.ietf-mmusic-4572-update]. In addition, the offerer MUST 333 insert in the offer an SDP 'dtls-id' attribute with a unique value. 335 If the offerer inserts the SDP 'setup' attribute with an 'actpass' or 336 'passive' attribute value, the offerer MUST be prepared to receive a 337 DTLS ClientHello message (if a new DTLS association is established by 338 the answerer) from the answerer before the offerer receives the SDP 339 answer. 341 5.3. Generating the Answer 343 When an answerer sends an answer, the answerer MUST insert in the 344 answer an SDP 'setup' attribute according to the procedures in 345 [RFC4145], and one or more SDP 'fingerprint' attributes according to 346 the procedures in [I-D.ietf-mmusic-4572-update]. If the answerer 347 determines, based on the criteria specified in Section 3.1, that a 348 new DTLS association is to be established, the answerer MUST insert 349 in the associated answer an SDP 'dtls-id' attribute with a new unique 350 value. Note that the offerer and answerer generate their own local 351 'dtls-id' attribute values, and the combination of both values 352 identify the DTLS association. 354 If the answerer receives an offer that requires establishment of a 355 new DTLS association, and if the answerer does not accept the 356 establishment of a new DTLS association, the answerer MUST reject the 357 "m=" lines associated with the suggested DTLS association [RFC3264]. 359 If an answerer receives an offer that does not require the 360 establishment of a new DTLS association, and if the answerer 361 determines that a new DTLS association is not to be established, the 362 answerer MUST insert an SDP 'dtls-id' attribute with the previously 363 assigned value in the associated answer. In addition, the answerer 364 MUST insert an SDP 'setup' attribute with a value that does not 365 change the previously negotiated DTLS roles, and one or more SDP 366 'fingerprint' attributes values that do not change the previously 367 sent fingerprint set, in the associated answer. 369 If the answerer receives an offer that does not contain an SDP 'dtls- 370 id' attribute, the answerer MUST NOT insert a 'dtls-id' attribute in 371 the answer. 373 If a new DTLS association is to be established, and if the answerer 374 inserts an SDP 'setup' attribute with an 'active' value in the 375 answer, the answerer MUST initiate a DTLS handshake by sending a DTLS 376 ClientHello message towards the offerer. 378 5.4. Offerer Processing of the SDP Answer 380 When an offerer receives an answer that establishes a new DTLS 381 association based on criteria defined in Section 3.1, and if the 382 offerer becomes DTLS client (based on the value of the SDP 'setup' 383 attribute value [RFC4145]), the offerer MUST establish a DTLS 384 association. If the offerer becomes DTLS server, it MUST wait for 385 the answerer to establish the DTLS association. 387 If the answer does not establish a new DTLS association, the offerer 388 will continue using the previously established DTLS association. 390 NOTE: A new DTLS association can be established based on changes in 391 either an SDP offer or answer. When communicating with legacy 392 endpoints, an offerer can receive an answer that includes the same 393 fingerprint set and setup role. A new DTLS association MUST still be 394 established if such an answer was received as a response to an offer 395 which requested the establishment of a new DTLS association. 397 5.5. Modifying the Session 399 When the offerer sends a subsequent offer, and if the offerer wants 400 to establish a new DTLS association, the offerer MUST insert an SDP 401 'setup' attribute according to the procedures in [RFC4145], and one 402 or more SDP 'fingerprint' attributes according to the procedures in 403 [I-D.ietf-mmusic-4572-update]. In addition, the offerer MUST insert 404 in the offer an SDP 'dtls-id' attribute with a new unique value. 406 When the offerer sends a subsequent offer, and the offerer does not 407 want to establish a new DTLS association, and if a previously 408 established DTLS association exists, the offerer MUST insert an SDP 409 'dtls-id' attribute with the previously assigned value in the offer. 410 In addition, the offerer MUST insert an SDP 'setup' attribute, and 411 one or more SDP 'fingerprint' attributes with values that do not 412 change the previously sent fingerprint set, in the offer. The value 413 of the 'setup' attribute SHOULD be set to 'actpass', in order to 414 allow the answerer to establish a new DTLS association with a 415 different role, but MAY be set to the current negotiated role 416 ('active' or 'passive'). It MUST NOT be set to a value that changes 417 the current negotiated role. 419 NOTE: When a new DTLS association is being established, each endpoint 420 needs to be prepared to receive data on both the new and old DTLS 421 associations as long as both are alive. 423 6. ICE Considerations 425 When the Interactive Connectivity Establishment (ICE) mechanism 426 [I-D.ietf-ice-rfc5245bis] is used, the ICE connectivity checks are 427 performed before the DTLS handshake begins. Note that if aggressive 428 nomination mode is used, multiple candidate pairs may be marked valid 429 before ICE finally converges on a single candidate pair. 431 NOTE: Aggressive nomination has been deprecated from ICE, but must 432 still be supported for backwards compatibility reasons. 434 When a new DTLS association is established over an unordered 435 transport, in order to disambiguate any packets associated with the 436 newly established DTLS association, at least one of the endpoints 437 MUST allocate a completely new set of ICE candidates which were not 438 recently used for any other DTLS association. This means the 439 answerer cannot initiate a new DTLS association unless the offerer 440 initiated ICE restart [I-D.ietf-ice-rfc5245bis]. If the answerer 441 wants to initiate a new DTLS association, it needs to initiate an ICE 442 restart and a new offer/answer exchange on its own. However, an ICE 443 restart does not by default require a new DTLS association to be 444 established. 446 NOTE: Simple Traversal of the UDP Protocol through NAT (STUN) packets 447 are sent directly over UDP, not over DTLS. [RFC5764] describes how 448 to demultiplex STUN packets from DTLS packets and SRTP packets. 450 Each ICE candidate associated with a component is treated as being 451 part of the same DTLS association. Therefore, from a DTLS 452 perspective it is not considered a change of local transport 453 parameters when an endpoint switches between those ICE candidates. 455 7. Transport Protocol Considerations 457 7.1. Transport Re-Usage 459 If DTLS is transported on top of a connection-oriented transport 460 protocol (e.g., TCP or SCTP), where all IP packets are acknowledged, 461 all DTLS packets associated with a previous DTLS association MUST be 462 acknowledged (or timed out) before a new DTLS association can be 463 established on the same instance of that transport (5-tuple). 465 8. SIP Considerations 467 When the Session Initiation Protocol (SIP) [RFC3261] is used as the 468 signal protocol for establishing a multimedia session, dialogs 469 [RFC3261] might be established between the caller and multiple 470 callees. This is referred to as forking. If forking occurs, 471 separate DTLS associations MUST be established between the caller and 472 each callee. 474 It is possible to send an INVITE request which does not contain an 475 SDP offer. Such an INVITE request is often referred to as an 'empty 476 INVITE', or an 'offer-less INVITE'. The receiving endpoint will 477 include the SDP offer in a response to the request. When the 478 endpoint generates such SDP offer, if a previously established DTLS 479 association exists, the offerer SHOULD insert an SDP 'dtls-id' 480 attribute, and one or more SDP 'fingerprint' attributes, with 481 previously assigned attribute values. If a previously established 482 DTLS association did not exist, the offer SHOULD be generated based 483 on the same rules as a new offer (see Section 5.2). Regardless of 484 the previous existence of a DTLS association, the SDP 'setup' 485 attribute MUST be included according to the rules defined in 486 [RFC4145] and if ICE is used, ICE restart MUST be initiated. 488 9. RFC Updates 490 9.1. General 492 This section updates specifications that use DTLS-protected media, in 493 order to reflect the procedures defined in this specification. 495 9.2. Update to RFC 5763 497 Update to section 5: 498 -------------------- 500 OLD TEXT: 502 5. Establishing a Secure Channel 504 The two endpoints in the exchange present their identities as part of 505 the DTLS handshake procedure using certificates. This document uses 506 certificates in the same style as described in "Connection-Oriented 507 Media Transport over the Transport Layer Security (TLS) Protocol in 508 the Session Description Protocol (SDP)" [RFC4572]. 510 If self-signed certificates are used, the content of the 511 subjectAltName attribute inside the certificate MAY use the uniform 512 resource identifier (URI) of the user. This is useful for debugging 513 purposes only and is not required to bind the certificate to one of 514 the communication endpoints. The integrity of the certificate is 515 ensured through the fingerprint attribute in the SDP. The 516 subjectAltName is not an important component of the certificate 517 verification. 519 The generation of public/private key pairs is relatively expensive. 520 Endpoints are not required to generate certificates for each session. 522 The offer/answer model, defined in [RFC3264], is used by protocols 523 like the Session Initiation Protocol (SIP) [RFC3261] to set up 524 multimedia sessions. In addition to the usual contents of an SDP 525 [RFC4566] message, each media description ("m=" line and associated 526 parameters) will also contain several attributes as specified in 527 [RFC5764], [RFC4145], and [RFC4572]. 529 When an endpoint wishes to set up a secure media session with another 530 endpoint, it sends an offer in a SIP message to the other endpoint. 531 This offer includes, as part of the SDP payload, the fingerprint of 532 the certificate that the endpoint wants to use. The endpoint SHOULD 533 send the SIP message containing the offer to the offerer's SIP proxy 534 over an integrity protected channel. The proxy SHOULD add an 535 Identity header field according to the procedures outlined in 536 [RFC4474]. The SIP message containing the offer SHOULD be sent to 537 the offerer's SIP proxy over an integrity protected channel. When 538 the far endpoint receives the SIP message, it can verify the identity 539 of the sender using the Identity header field. Since the Identity 540 header field is a digital signature across several SIP header fields, 541 in addition to the body of the SIP message, the receiver can also be 542 certain that the message has not been tampered with after the digital 543 signature was applied and added to the SIP message. 545 The far endpoint (answerer) may now establish a DTLS association with 546 the offerer. Alternately, it can indicate in its answer that the 547 offerer is to initiate the TLS association. In either case, mutual 548 DTLS certificate-based authentication will be used. After completing 549 the DTLS handshake, information about the authenticated identities, 550 including the certificates, are made available to the endpoint 551 application. The answerer is then able to verify that the offerer's 552 certificate used for authentication in the DTLS handshake can be 553 associated to the certificate fingerprint contained in the offer in 554 the SDP. At this point, the answerer may indicate to the end user 555 that the media is secured. The offerer may only tentatively accept 556 the answerer's certificate since it may not yet have the answerer's 557 certificate fingerprint. 559 When the answerer accepts the offer, it provides an answer back to 560 the offerer containing the answerer's certificate fingerprint. At 561 this point, the offerer can accept or reject the peer's certificate 562 and the offerer can indicate to the end user that the media is 563 secured. 565 Note that the entire authentication and key exchange for securing the 566 media traffic is handled in the media path through DTLS. The 567 signaling path is only used to verify the peers' certificate 568 fingerprints. 570 The offer and answer MUST conform to the following requirements. 572 o The endpoint MUST use the setup attribute defined in [RFC4145]. 573 The endpoint that is the offerer MUST use the setup attribute 574 value of setup:actpass and be prepared to receive a client_hello 575 before it receives the answer. The answerer MUST use either a 576 setup attribute value of setup:active or setup:passive. Note that 577 if the answerer uses setup:passive, then the DTLS handshake will 578 not begin until the answerer is received, which adds additional 579 latency. setup:active allows the answer and the DTLS handshake to 580 occur in parallel. Thus, setup:active is RECOMMENDED. Whichever 581 party is active MUST initiate a DTLS handshake by sending a 582 ClientHello over each flow (host/port quartet). 584 o The endpoint MUST NOT use the connection attribute defined in 585 [RFC4145]. 587 o The endpoint MUST use the certificate fingerprint attribute as 588 specified in [RFC4572]. 590 o The certificate presented during the DTLS handshake MUST match the 591 fingerprint exchanged via the signaling path in the SDP. The 592 security properties of this mechanism are described in Section 8. 594 o If the fingerprint does not match the hashed certificate, then the 595 endpoint MUST tear down the media session immediately. Note that 596 it is permissible to wait until the other side's fingerprint has 597 been received before establishing the connection; however, this 598 may have undesirable latency effects. 600 NEW TEXT: 602 5. Establishing a Secure Channel 604 The two endpoints in the exchange present their identities as part of 605 the DTLS handshake procedure using certificates. This document uses 606 certificates in the same style as described in "Connection-Oriented 607 Media Transport over the Transport Layer Security (TLS) Protocol in 608 the Session Description Protocol (SDP)" [RFC4572]. 610 If self-signed certificates are used, the content of the 611 subjectAltName attribute inside the certificate MAY use the uniform 612 resource identifier (URI) of the user. This is useful for debugging 613 purposes only and is not required to bind the certificate to one of 614 the communication endpoints. The integrity of the certificate is 615 ensured through the fingerprint attribute in the SDP. 617 The generation of public/private key pairs is relatively expensive. 618 Endpoints are not required to generate certificates for each session. 620 The offer/answer model, defined in [RFC3264], is used by protocols 621 like the Session Initiation Protocol (SIP) [RFC3261] to set up 622 multimedia sessions. 624 When an endpoint wishes to set up a secure media session with another 625 endpoint, it sends an offer in a SIP message to the other endpoint. 626 This offer includes, as part of the SDP payload, a fingerprint of 627 a certificate that the endpoint wants to use. The endpoint SHOULD 628 send the SIP message containing the offer to the offerer's SIP proxy 629 over an integrity protected channel. The proxy SHOULD add an 630 Identity header field according to the procedures outlined in 631 [RFC4474]. The SIP message containing the offer SHOULD be sent to 632 the offerer's SIP proxy over an integrity protected channel. When 633 the far endpoint receives the SIP message, it can verify the identity 634 of the sender using the Identity header field. Since the Identity 635 header field is a digital signature across several SIP header fields, 636 in addition to the body of the SIP message, the receiver can also be 637 certain that the message has not been tampered with after the digital 638 signature was applied and added to the SIP message. 640 The far endpoint (answerer) may now establish a DTLS association with 641 the offerer. Alternately, it can indicate in its answer that the 642 offerer is to initiate the DTLS association. In either case, mutual 643 DTLS certificate-based authentication will be used. After completing 644 the DTLS handshake, information about the authenticated identities, 645 including the certificates, are made available to the endpoint 646 application. The answerer is then able to verify that the offerer's 647 certificate used for authentication in the DTLS handshake can be 648 associated to the certificate fingerprint contained in the offer in 649 the SDP. At this point, the answerer may indicate to the end user 650 that the media is secured. The offerer may only tentatively accept 651 the answerer's certificate since it may not yet have the answerer's 652 certificate fingerprint. 654 When the answerer accepts the offer, it provides an answer back to 655 the offerer containing the answerer's certificate fingerprint. At 656 this point, the offerer can accept or reject the peer's certificate 657 and the offerer can indicate to the end user that the media is 658 secured. 660 Note that the entire authentication and key exchange for securing 661 the media traffic is handled in the media path through DTLS. The 662 signaling path is only used to verify the peers' certificate 663 fingerprints. 665 The offerer and answerer MUST follow the SDP offer/answer procedures 666 defined in [RFCXXXX]. 668 Update to section 6.6: 669 ---------------------- 671 OLD TEXT: 673 6.6. Session Modification 675 Once an answer is provided to the offerer, either endpoint MAY 676 request a session modification that MAY include an updated offer. 677 This session modification can be carried in either an INVITE or 678 UPDATE request. The peers can reuse the existing associations if 679 they are compatible (i.e., they have the same key fingerprints and 680 transport parameters), or establish a new one following the same 681 rules are for initial exchanges, tearing down the existing 682 association as soon as the offer/answer exchange is completed. Note 683 that if the active/passive status of the endpoints changes, a new 684 connection MUST be established. 686 NEW TEXT: 688 6.6. Session Modification 690 Once an answer is provided to the offerer, either endpoint MAY 691 request a session modification that MAY include an updated offer. 693 This session modification can be carried in either an INVITE or 694 UPDATE request. The peers can reuse an existing DTLS association, 695 or establish a new one, following the procedures in [RFCXXXX]. 697 Update to section 6.7.1: 698 ------------------------ 700 OLD TEXT: 702 6.7.1. ICE Interaction 704 Interactive Connectivity Establishment (ICE), as specified in 705 [RFC5245], provides a methodology of allowing participants in 706 multimedia sessions to verify mutual connectivity. When ICE is being 707 used, the ICE connectivity checks are performed before the DTLS 708 handshake begins. Note that if aggressive nomination mode is used, 709 multiple candidate pairs may be marked valid before ICE finally 710 converges on a single candidate pair. Implementations MUST treat all 711 ICE candidate pairs associated with a single component as part of the 712 same DTLS association. Thus, there will be only one DTLS handshake 713 even if there are multiple valid candidate pairs. Note that this may 714 mean adjusting the endpoint IP addresses if the selected candidate 715 pair shifts, just as if the DTLS packets were an ordinary media 716 stream. 718 Note that Simple Traversal of the UDP Protocol through NAT (STUN) 719 packets are sent directly over UDP, not over DTLS. [RFC5764] 720 describes how to demultiplex STUN packets from DTLS packets and SRTP 721 packets. 723 NEW TEXT: 725 6.7.1. ICE Interaction 727 The Interactive Connectivity Establishment (ICE) 728 [I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media 729 are described in [RFCXXXX]. 731 9.3. Update to RFC 7345 733 Update to section 4: 734 -------------------- 736 OLD TEXT: 738 4. SDP Offerer/Answerer Procedures 739 4.1. General 741 An endpoint (i.e., both the offerer and the answerer) MUST create an 742 SDP media description ("m=" line) for each UDPTL-over-DTLS media 743 stream and MUST assign a UDP/TLS/UDPTL value (see Table 1) to the 744 "proto" field of the "m=" line. 746 The procedures in this section apply to an "m=" line associated with 747 a UDPTL-over-DTLS media stream. 749 In order to negotiate a UDPTL-over-DTLS media stream, the following 750 SDP attributes are used: 752 o The SDP attributes defined for UDPTL over UDP, as described in 753 [ITU.T38.2010]; and 755 o The SDP attributes, defined in [RFC4145] and [RFC4572], as 756 described in this section. 758 The endpoint MUST NOT use the SDP "connection" attribute [RFC4145]. 760 In order to negotiate the TLS roles for the UDPTL-over-DTLS transport 761 connection, the endpoint MUST use the SDP "setup" attribute 762 [RFC4145]. 764 If the endpoint supports, and is willing to use, a cipher suite with 765 an associated certificate, the endpoint MUST include an SDP 766 "fingerprint" attribute [RFC4572]. The endpoint MUST support SHA-256 767 for generating and verifying the SDP "fingerprint" attribute value. 768 The use of SHA-256 is preferred. UDPTL over DTLS, at a minimum, MUST 769 support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support 770 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. UDPTL over DTLS MUST prefer 771 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and any other Perfect Forward 772 Secrecy (PFS) cipher suites over non-PFS cipher suites. 773 Implementations SHOULD disable TLS-level compression. 775 If a cipher suite with an associated certificate is selected during 776 the DTLS handshake, the certificate received during the DTLS 777 handshake MUST match the fingerprint received in the SDP 778 "fingerprint" attribute. If the fingerprint does not match the 779 hashed certificate, then the endpoint MUST tear down the media 780 session immediately. Note that it is permissible to wait until the 781 other side's fingerprint has been received before establishing the 782 connection; however, this may have undesirable latency effects. 784 4.2. Generating the Initial Offer 786 The offerer SHOULD assign the SDP "setup" attribute with a value of 787 "actpass", unless the offerer insists on being either the sender or 788 receiver of the DTLS ClientHello message, in which case the offerer 789 can use either a value of "active" (the offerer will be the sender of 790 ClientHello) or "passive" (the offerer will be the receiver of 791 ClientHello). The offerer MUST NOT assign an SDP "setup" attribute 792 with a "holdconn" value. 794 If the offerer assigns the SDP "setup" attribute with a value of 795 "actpass" or "passive", the offerer MUST be prepared to receive a 796 DTLS ClientHello message before it receives the SDP answer. 798 4.3. Generating the Answer 800 If the answerer accepts the offered UDPTL-over-DTLS transport 801 connection, in the associated SDP answer, the answerer MUST assign an 802 SDP "setup" attribute with a value of either "active" or "passive", 803 according to the procedures in [RFC4145]. The answerer MUST NOT 804 assign an SDP "setup" attribute with a value of "holdconn". 806 If the answerer assigns an SDP "setup" attribute with a value of 807 "active" value, the answerer MUST initiate a DTLS handshake by 808 sending a DTLS ClientHello message on the negotiated media stream, 809 towards the IP address and port of the offerer. 811 4.4. Offerer Processing of the Answer 813 When the offerer receives an SDP answer, if the offerer ends up being 814 active it MUST initiate a DTLS handshake by sending a DTLS 815 ClientHello message on the negotiated media stream, towards the IP 816 address and port of the answerer. 818 4.5. Modifying the Session 820 Once an offer/answer exchange has been completed, either endpoint MAY 821 send a new offer in order to modify the session. The endpoints can 822 reuse the existing DTLS association if the key fingerprint values and 823 transport parameters indicated by each endpoint are unchanged. 824 Otherwise, following the rules for the initial offer/answer exchange, 825 the endpoints can negotiate and create a new DTLS association and, 826 once created, delete the previous DTLS association, following the 827 same rules for the initial offer/answer exchange. Each endpoint 828 needs to be prepared to receive data on both the new and old DTLS 829 associations as long as both are alive. 831 NEW TEXT: 833 4. SDP Offerer/Answerer Procedures 834 An endpoint (i.e., both the offerer and the answerer) MUST create an 835 SDP media description ("m=" line) for each UDPTL-over-DTLS media 836 stream and MUST assign a UDP/TLS/UDPTL value (see Table 1) to the 837 "proto" field of the "m=" line. 839 The offerer and answerer MUST follow the SDP offer/answer procedures 840 defined in [RFCXXXX] in order to negotiate the DTLS association 841 associated with the UDPTL-over-DTLS media stream. In addition, 842 the offerer and answerer MUST use the SDP attributes defined for 843 UDPTL over UDP, as defined in [ITU.T38.2010]. 845 Update to section 5.2.1: 846 ------------------------ 848 OLD TEXT: 850 5.2.1. ICE Usage 852 When Interactive Connectivity Establishment (ICE) [RFC5245] is being 853 used, the ICE connectivity checks are performed before the DTLS 854 handshake begins. Note that if aggressive nomination mode is used, 855 multiple candidate pairs may be marked valid before ICE finally 856 converges on a single candidate pair. User Agents (UAs) MUST treat 857 all ICE candidate pairs associated with a single component as part 858 of the same DTLS association. Thus, there will be only one DTLS 859 handshake even if there are multiple valid candidate pairs. Note 860 that this may mean adjusting the endpoint IP addresses if the 861 selected candidate pair shifts, just as if the DTLS packets were an 862 ordinary media stream. In the case of an ICE restart, the DTLS 863 handshake procedure is repeated, and a new DTLS association is 864 created. Once the DTLS handshake is completed and the new DTLS 865 association has been created, the previous DTLS association is 866 deleted. 868 NEW TEXT: 870 5.2.1. ICE Usage 872 The Interactive Connectivity Establishment (ICE) 873 [I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media 874 are described in [RFCXXXX]. 876 10. Security Considerations 878 This specification does not modify the security considerations 879 associated with DTLS, or the SDP offer/answer mechanism. In addition 880 to the introduction of the SDP 'dtls-id' attribute, the specification 881 simply clarifies the procedures for negotiating and establishing a 882 DTLS association. 884 11. IANA Considerations 886 This document updates the "Session Description Protocol Parameters" 887 registry as specified in Section 8.2.2 of [RFC4566]. Specifically, 888 it adds the SDP 'dtls-id' attribute to the table for SDP media level 889 attributes. 891 Attribute name: dtls-id 892 Type of attribute: media-level 893 Subject to charset: no 894 Purpose: Indicates whether a new DTLS association is to be 895 established/re-established. 896 Appropriate Values: see Section 4 897 Contact name: Christer Holmberg 898 Mux Category: IDENTICAL 900 12. Acknowledgements 902 Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat, Jens Guballa, 903 Charles Eckel, Gonzalo Salgueiro and Paul Jones for providing 904 comments and suggestions on the document. 906 13. Change Log 908 [RFC EDITOR NOTE: Please remove this section when publishing] 910 Changes from draft-ietf-mmusic-sdp-dtls-20 912 o Change to length and randomness of dtls-id attribute value. 914 Changes from draft-ietf-mmusic-sdp-dtls-19 916 o Change based on comment from Roman. 918 Changes from draft-ietf-mmusic-sdp-dtls-18 920 o Changes based on comments from Flemming. 922 o - Change in dtls-id value definition. 924 o - Editorial fixes. 926 Changes from draft-ietf-mmusic-sdp-dtls-17 928 o Reference fix. 930 Changes from draft-ietf-mmusic-sdp-dtls-16 932 o Editorial changes based on 2nd WGLC comments from Christian Groves 933 and Nevenka Biondic. 935 Changes from draft-ietf-mmusic-sdp-dtls-15 937 o dtls-id attribute value made globally unique 939 Changes from draft-ietf-mmusic-sdp-dtls-14 941 o Changes based on comments from Flemming: 943 o - Additional dtls-is clarifiations 945 o - Editorial fixes 947 Changes from draft-ietf-mmusic-sdp-dtls-13 949 o Text about the updated RFCs added to Abstract and Introduction 951 o Reference to RFC 5763 removed from section 6 (ICE Considerations) 953 o Reference to RFC 5763 removed from section 8 (SIP Considerations) 955 Changes from draft-ietf-mmusic-sdp-dtls-12 957 o "unreliable" changed to "unordered" 959 Changes from draft-ietf-mmusic-sdp-dtls-11 961 o Attribute name changed to dtls-id 963 o Additional text based on comments from Roman Shpount. 965 Changes from draft-ietf-mmusic-sdp-dtls-10 967 o Modified document to use dtls-id instead of dtls-connection 968 o Changes are based on comments from Eric Rescorla, Justin Uberti, 969 and Paul Kyzivat. 971 Changes from draft-ietf-mmusic-sdp-dtls-08 973 o Offer/Answer section modified in order to allow sending of 974 multiple SDP 'fingerprint' attributes. 976 o Terminology made consistent: 'DTLS connection' replaced with 'DTLS 977 association'. 979 o Editorial changes based on comments from Paul Kyzivat. 981 Changes from draft-ietf-mmusic-sdp-dtls-07 983 o Reference to RFC 7315 replaced with reference to RFC 7345. 985 Changes from draft-ietf-mmusic-sdp-dtls-06 987 o Text on restrictions regarding spanning a DTLS association over 988 multiple transports added. 990 o Mux category added to IANA Considerations. 992 o Normative text regarding mux category and source-specific 993 applicability added. 995 o Reference to RFC 7315 added. 997 o Clarified that offerer/answerer that has not been updated to 998 support this specification will not include the dtls-id attribute 999 in offers and answers. 1001 o Editorial corrections based on WGLC comments from Charles Eckel. 1003 Changes from draft-ietf-mmusic-sdp-dtls-05 1005 o Text on handling offer/answer error conditions added. 1007 Changes from draft-ietf-mmusic-sdp-dtls-04 1009 o Editorial nits fixed based on comments from Paul Kyzivat: 1011 Changes from draft-ietf-mmusic-sdp-dtls-03 1013 o Changes based on comments from Paul Kyzivat: 1015 o - Modification of dtls-id attribute section. 1017 o - Removal of IANA considerations subsection. 1019 o - Making note into normative text in o/a section. 1021 o Changes based on comments from Martin Thompson: 1023 o - Abbreviations section removed. 1025 o - Clarify that a new DTLS association requires a new o/a 1026 transaction. 1028 Changes from draft-ietf-mmusic-sdp-dtls-02 1030 o - Updated RFCs added to boilerplate. 1032 Changes from draft-ietf-mmusic-sdp-dtls-01 1034 o - Annex regarding 'dtls-id-id' attribute removed. 1036 o - Additional SDP offer/answer procedures, related to certificates, 1037 added. 1039 o - Updates to RFC 5763 and RFC 7345 added. 1041 o - Transport protocol considerations added. 1043 Changes from draft-ietf-mmusic-sdp-dtls-00 1045 o - SDP 'connection' attribute replaced with new 'dtls-id' 1046 attribute. 1048 o - IANA Considerations added. 1050 o - E-mail regarding 'dtls-id-id' attribute added as Annex. 1052 Changes from draft-holmberg-mmusic-sdp-dtls-01 1054 o - draft-ietf-mmusic version of draft submitted. 1056 o - Draft file name change (sdp-dtls -> dtls-sdp) due to collision 1057 with another expired draft. 1059 o - Clarify that if ufrag in offer is unchanged, it must be 1060 unchanged in associated answer. 1062 o - SIP Considerations section added. 1064 o - Section about multiple SDP fingerprint attributes added. 1066 Changes from draft-holmberg-mmusic-sdp-dtls-00 1068 o - Editorial changes and clarifications. 1070 14. References 1072 14.1. Normative References 1074 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1075 Requirement Levels", BCP 14, RFC 2119, 1076 DOI 10.17487/RFC2119, March 1997, 1077 . 1079 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1080 A., Peterson, J., Sparks, R., Handley, M., and E. 1081 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1082 DOI 10.17487/RFC3261, June 2002, 1083 . 1085 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1086 with Session Description Protocol (SDP)", RFC 3264, 1087 DOI 10.17487/RFC3264, June 2002, 1088 . 1090 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 1091 the Session Description Protocol (SDP)", RFC 4145, 1092 DOI 10.17487/RFC4145, September 2005, 1093 . 1095 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1096 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1097 July 2006, . 1099 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1100 for Establishing a Secure Real-time Transport Protocol 1101 (SRTP) Security Context Using Datagram Transport Layer 1102 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 1103 2010, . 1105 [RFC7345] Holmberg, C., Sedlacek, I., and G. Salgueiro, "UDP 1106 Transport Layer (UDPTL) over Datagram Transport Layer 1107 Security (DTLS)", RFC 7345, DOI 10.17487/RFC7345, August 1108 2014, . 1110 [I-D.ietf-mmusic-4572-update] 1111 Lennox, J. and C. Holmberg, "Connection-Oriented Media 1112 Transport over TLS in SDP", draft-ietf-mmusic- 1113 4572-update-12 (work in progress), January 2017. 1115 14.2. Informative References 1117 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1118 Authenticated Identity Management in the Session 1119 Initiation Protocol (SIP)", RFC 4474, 1120 DOI 10.17487/RFC4474, August 2006, 1121 . 1123 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 1124 Transport Layer Security (TLS) Protocol in the Session 1125 Description Protocol (SDP)", RFC 4572, 1126 DOI 10.17487/RFC4572, July 2006, 1127 . 1129 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1130 (ICE): A Protocol for Network Address Translator (NAT) 1131 Traversal for Offer/Answer Protocols", RFC 5245, 1132 DOI 10.17487/RFC5245, April 2010, 1133 . 1135 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 1136 Media Attributes in the Session Description Protocol 1137 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 1138 . 1140 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1141 Security (DTLS) Extension to Establish Keys for the Secure 1142 Real-time Transport Protocol (SRTP)", RFC 5764, 1143 DOI 10.17487/RFC5764, May 2010, 1144 . 1146 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 1147 Transport Layer Security (DTLS) for Stream Control 1148 Transmission Protocol (SCTP)", RFC 6083, 1149 DOI 10.17487/RFC6083, January 2011, 1150 . 1152 [I-D.ietf-ice-rfc5245bis] 1153 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 1154 Connectivity Establishment (ICE): A Protocol for Network 1155 Address Translator (NAT) Traversal", draft-ietf-ice- 1156 rfc5245bis-08 (work in progress), December 2016. 1158 [I-D.ietf-mmusic-sdp-mux-attributes] 1159 Nandakumar, S., "A Framework for SDP Attributes when 1160 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 1161 (work in progress), December 2016. 1163 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1164 Holmberg, C., Alvestrand, H., and C. Jennings, 1165 "Negotiating Media Multiplexing Using the Session 1166 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1167 negotiation-36 (work in progress), October 2016. 1169 [ITU.T38.2010] 1170 International Telecommunications Union, "Procedures for 1171 real-time Group 3 facsimile communication over IP 1172 networks", ITU-T Recommendation T.38, September 2010. 1174 Authors' Addresses 1176 Christer Holmberg 1177 Ericsson 1178 Hirsalantie 11 1179 Jorvas 02420 1180 Finland 1182 Email: christer.holmberg@ericsson.com 1184 Roman Shpount 1185 TurboBridge 1186 4905 Del Ray Avenue, Suite 300 1187 Bethesda, MD 20814 1188 USA 1190 Phone: +1 (240) 292-6632 1191 Email: rshpount@turbobridge.com