idnits 2.17.1 draft-ietf-mmusic-msrp-usage-data-channel-12.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 10, 2019) is 1693 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) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC K. Drage, Ed. 3 Internet-Draft M. Makaraju 4 Intended status: Standards Track J. Stoetzer-Bradler 5 Expires: February 11, 2020 R. Ejzak 6 J. Marcon 7 Unaffiliated 8 J. Recio, Ed. 9 CoSMo Software 10 August 10, 2019 12 MSRP over Data Channels 13 draft-ietf-mmusic-msrp-usage-data-channel-12 15 Abstract 17 This document specifies how the Message Session Relay Protocol (MSRP) 18 can be instantiated as a data channel sub-protocol, using the SDP 19 offer/answer exchange-based generic data channel negotiation 20 framework. Two network configurations are documented: a WebRTC end- 21 to-end configuration (connecting two MSRP over data channel 22 endpoints), and a gateway configuration (connecting an MSRP over data 23 channel endpoint with an MSRP over TCP or TLS endpoint). 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on February 11, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.1. MSRP Data Channel . . . . . . . . . . . . . . . . . . . . 5 64 4.2. Session Mapping . . . . . . . . . . . . . . . . . . . . . 5 65 4.3. MSRP URI . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.4. msrp-scheme . . . . . . . . . . . . . . . . . . . . . . . 5 67 5. End-to-End Configuration . . . . . . . . . . . . . . . . . . 5 68 5.1. Basic MSRP Support . . . . . . . . . . . . . . . . . . . 6 69 5.1.1. Session Negotiation . . . . . . . . . . . . . . . . . 6 70 5.1.1.1. Use of the dcmap Attribute . . . . . . . . . . . 6 71 5.1.1.2. Use of the dcsa Attribute . . . . . . . . . . . . 6 72 5.1.1.3. Use of the setup Attribute . . . . . . . . . . . 7 73 5.1.1.4. Example SDP Negotiation . . . . . . . . . . . . . 8 74 5.1.2. Session Opening . . . . . . . . . . . . . . . . . . . 8 75 5.1.3. Data Framing . . . . . . . . . . . . . . . . . . . . 9 76 5.1.4. Data Sending and Reporting . . . . . . . . . . . . . 9 77 5.1.5. Session Closing . . . . . . . . . . . . . . . . . . . 9 78 5.2. Support for MSRP File Transfer Function . . . . . . . . . 9 79 6. Gateway Configuration . . . . . . . . . . . . . . . . . . . . 10 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 7.1. Subprotocol Identifier MSRP . . . . . . . . . . . . . . . 11 82 7.2. setup Attribute . . . . . . . . . . . . . . . . . . . . . 11 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 85 10. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 10.1. Changes against 'draft-ietf-mmusic-msrp-usage-data- 87 channel-11' . . . . . . . . . . . . . . . . . . . . . . 12 88 10.2. Changes against 'draft-ietf-mmusic-msrp-usage-data- 89 channel-10' . . . . . . . . . . . . . . . . . . . . . . 12 90 10.3. Changes against 'draft-ietf-mmusic-msrp-usage-data- 91 channel-09' . . . . . . . . . . . . . . . . . . . . . . 12 92 10.4. Changes against 'draft-ietf-mmusic-msrp-usage-data- 93 channel-08' . . . . . . . . . . . . . . . . . . . . . . 13 94 10.5. Changes against 'draft-ietf-mmusic-msrp-usage-data- 95 channel-07' . . . . . . . . . . . . . . . . . . . . . . 13 96 10.6. Changes against 'draft-ietf-mmusic-msrp-usage-data- 97 channel-06' . . . . . . . . . . . . . . . . . . . . . . 13 98 10.7. Changes against 'draft-ietf-mmusic-msrp-usage-data- 99 channel-05' . . . . . . . . . . . . . . . . . . . . . . 13 100 10.8. Changes against 'draft-ietf-mmusic-msrp-usage-data- 101 channel-04' . . . . . . . . . . . . . . . . . . . . . . 13 102 10.9. Changes against 'draft-ietf-mmusic-msrp-usage-data- 103 channel-03' . . . . . . . . . . . . . . . . . . . . . . 13 104 10.10. Changes against 'draft-ietf-mmusic-msrp-usage-data- 105 channel-02' . . . . . . . . . . . . . . . . . . . . . . 14 106 10.11. Changes against 'draft-ietf-mmusic-msrp-usage-data- 107 channel-01' . . . . . . . . . . . . . . . . . . . . . . 14 108 10.12. Changes against 'draft-ietf-mmusic-msrp-usage-data- 109 channel-00' . . . . . . . . . . . . . . . . . . . . . . 16 110 10.13. Changes against 'draft-ejzak-mmusic-msrp-usage-data- 111 channel-01' . . . . . . . . . . . . . . . . . . . . . . 16 112 10.14. Changes against '-00' . . . . . . . . . . . . . . . . . 17 113 11. Normative References . . . . . . . . . . . . . . . . . . . . 17 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 116 1. Introduction 118 The Message Session Relay Protocol (MSRP) [RFC4975] is a protocol for 119 transmitting a series of related instant messages in the context of a 120 session. In addition to instant messaging, MSRP can also be used for 121 image sharing or file transfer. MSRP is currently defined to work 122 over TCP and TLS connections, and over a WebSocket subprotocol 123 specified by [RFC7977]. 125 This document defines the negotiation and transport of this MSRP 126 protocol over data channels, where a data channel is a bi-directional 127 communication channel running on top of SCTP/DTLS (as per 128 [I-D.ietf-rtcweb-data-channel]) and where MSRP is instantiated as a 129 sub-protocol of this data channel. The MSRP protocol negotiation 130 defined in this document is based on the generic SDP offer/answer 131 exchange based data channel negotiation as specified in 132 [I-D.ietf-mmusic-data-channel-sdpneg]. 134 Defining MSRP as a data channel sub-protocol has many benefits: 136 o provides to applications a proven protocol enabling instant 137 messaging, file transfer, image sharing 139 o integrates those features with other RTCWeb voice, video and data 140 features 142 o leverages the SDP-based negotiation already defined for MSRP 143 o allows the interworking with MSRP endpoints running on a TCP or 144 TLS connection 146 Compared to WebSockets, that provide a message passing protocol to 147 applications with no direct access to TCP or TLS sockets, data 148 channels provide a low latency transport, leverage NAT-aware 149 connectivity and security features of WebRTC, and are increasingly 150 available not only in modern browsers but in other applications that 151 use WebRTC for media or other purposes (IoT or telemetry in general, 152 non-media data exchange, etc). 154 Considering an MSRP endpoint being an MSRP application that uses data 155 channel from WebRTC specifications [I-D.ietf-rtcweb-data-channel], 156 this document describes two configurations where the other endpoint 157 is respectively either another MSRP over data channel endpoint (e.g., 158 a WebRTC application) or an MSRP endpoint using either TCP or TLS 159 transport. 161 2. Conventions 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119]. 167 3. Terminology 169 This document uses the following terms: 171 Data channel: A WebRTC data channel as specified in 172 [I-D.ietf-rtcweb-data-channel]. 174 MSRP data channel: A data channel specifically used to transport 175 the messages of one MSRP session. 177 External negotiation: Data channel negotiation based on out-of- 178 band or in-band mechanisms other than the Data Channel 179 Establishment Protocol specified in 180 [I-D.ietf-rtcweb-data-protocol]. 182 In-band: Transmission through the peer-to-peer SCTP association. 184 Out-of-band: Transmission through the call control signaling path, 185 e.g., using JSEP [I-D.ietf-rtcweb-jsep] and the SDP Offer/Answer 186 model [RFC3264]. 188 Peer: From the perspective of one of the agents in a session, its 189 peer is the other agent. Specifically, from the perspective of 190 the SDP offerer, the peer is the SDP answerer. From the 191 perspective of the SDP answerer, the peer is the SDP offerer. 193 4. Principles 195 4.1. MSRP Data Channel 197 In this document, an MSRP data channel is a data channel for which 198 the instantiated sub-protocol is "MSRP", and where the MSRP-related 199 negotiation is done as part of the SDP-based external negotiation 200 method defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 202 4.2. Session Mapping 204 In this design, the MSRP session maps to the SCTP association and the 205 "SCTP stream pair" assigned to the data channel, and each MSRP 206 session maps to one data channel exactly. 208 4.3. MSRP URI 210 This document extends the MSRP URI syntax [RFC4975] by defining the 211 new transport parameter value "dc": 213 transport /= "dc" / 1*ALPHANUM 214 ; Add "dc" to existing transports per [RFC4975] 216 MSRP design provides for new transport bindings, see Section 6 of 217 [RFC4975], MSRP implementations are expected to allow unrecognized 218 transports for which there is no need to establish a connection to 219 the resource described by the URI, as it's the case of data channels 220 (Section 5.1.2). 222 4.4. msrp-scheme 224 The msrp-scheme portion of the MSRP-URI that represents an MSRP data 225 channel endpoint (used in the SDP path attribute and in the MSRP 226 message headers) is always "msrps", which indicates that the MSRP 227 data channel is always secured using DTLS as described in 228 [I-D.ietf-rtcweb-data-channel]. 230 5. End-to-End Configuration 232 This section describes the network configuration where each MSRP 233 endpoint is running MSRP over a data channel. 235 5.1. Basic MSRP Support 237 5.1.1. Session Negotiation 239 5.1.1.1. Use of the dcmap Attribute 241 The SDP offer SHALL include a dcmap attribute line (defined in 242 [I-D.ietf-mmusic-data-channel-sdpneg]) within the media description 243 of the SCTP association for each MSRP data channel session to be 244 negotiated. 246 The attribute includes the following data channel parameters: 248 o "label=" labelstring 250 o "subprotocol=" "MSRP" 252 The labelstring is set by the MSRP application according to 253 [I-D.ietf-mmusic-data-channel-sdpneg]. Ordered and reliable data 254 channels MUST always be used, so that the "max-retr" and "max-time" 255 parameters SHALL NOT be used. If the "ordered" parameter is used, 256 then its value MUST be equal to "true". 258 Rest of the SDP offer/answer procedures are per 259 [I-D.ietf-mmusic-data-channel-sdpneg]. 261 The following is an example of the dcmap attribute for an MSRP 262 session to be negotiated with stream-id=2 and label="chat": 264 a=dcmap:2 label="chat";subprotocol="MSRP" 266 5.1.1.2. Use of the dcsa Attribute 268 The SDP offer SHALL also include within the media description for the 269 SCTP association, a dcsa attribute line (defined in 270 [I-D.ietf-mmusic-data-channel-sdpneg]) for each MSRP-specific SDP 271 attribute to be negotiated for each MSRP data channel being 272 negotiated. 274 The MSRP-specific items that can be negotiated include at least all 275 of the following well-known attributes: 277 o defined in [RFC4975]: "path", "accept-types", "accept-wrapped- 278 types", "max-size" 280 o defined in [RFC4566]: "sendonly", "recvonly", "inactive", and 281 "sendrecv" 283 o defined in [RFC6135]: "setup" 285 o defined in [RFC5547]: all the parameters related to MSRP file 286 transfer. See Section 5.2. 288 MSRP Connection Establishment for Media Anchoring (MSRP-CEMA) 289 [RFC6714] is outside of the scope of this document. The msrp-cema 290 attribute SHALL NOT be present. 292 As described in Section 5.1.2 the path attribute is not used for 293 transport establiment. 295 The SDP answer SHALL include zero or more corresponding dcsa 296 attribute lines for each negotiated MSRP session, according to the 297 MSRP-specific attribute negotiation rules in the corresponding 298 specifications. 300 A new SDP offer/answer MAY update the MSRP subprotocol attributes 301 while keeping the same subprotocol a=dcmap description. The 302 semantics for newly negotiated MSRP subprotocol attributes are per 303 [RFC4975]. 305 5.1.1.3. Use of the setup Attribute 307 A dsca embedded setup attribute, as defined in [RFC4145], MUST be 308 used for MSRP sessions over data channels. It is used to negotiate 309 which MSRP session endpoint assumes the active role as per 310 Section 4.2.2 of [RFC6135] and Section 5.4 of [RFC4975]. It has no 311 relationship with the DTLS connection establishment roles. 313 The dcsa embedded setup attribute is of the form "a=dcsa:x 314 setup:", with x being the data channel's SCTP stream 315 identifier, so that such attribute is explicitly associated with an 316 MSRP session over a specific data channel. 318 It is considered an error if an MSRP over data channel description 319 does not contain a dcsa embedded setup attribute. 321 The SDP setup attribute can also be used in WebRTC data channel 322 related SDP media descriptions as a media level attribute, which is 323 associated with the corresponding UDP/DTLS/SCTP or TCP/DTLS/SCTP "m" 324 line. Such an "a=setup" attribute is used as specified in 325 [I-D.ietf-mmusic-sctp-sdp] in order to negotiate the establishment 326 roles of the DTLS connection and has no relationship with the MSRP 327 session. 329 5.1.1.4. Example SDP Negotiation 331 The following is an example of an "m" line for data channels in an 332 SDP offer that includes the attributes needed to establish two MSRP 333 sessions: one for chat and one for file transfer. The example is 334 derived from a combination of examples in [RFC4975] and [RFC5547]. 336 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 337 c=IN IP4 198.51.100.79 338 a=max-message-size:100000 339 a=sctp-port:5000 340 a=setup:actpass 341 a=fingerprint:SHA-1 \ 342 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 343 a=tls-id:4a756565cddef001be82 344 a=dcmap:0 label="chat";subprotocol="MSRP" 345 a=dcsa:0 setup:active 346 a=dcsa:0 accept-types:message/cpim text/plain 347 a=dcsa:0 path:msrps://bob.example.com:54111/si438dsaodes;dc 348 a=dcmap:2 label="file transfer";subprotocol="MSRP" 349 a=dcsa:2 sendonly 350 a=dcsa:2 setup:active 351 a=dcsa:2 accept-types:message/cpim 352 a=dcsa:2 accept-wrapped-types:* 353 a=dcsa:2 path:msrps://bob.example.com:54111/jshA7we;dc 354 a=dcsa:2 file-selector:name:"picture1.jpg" \ 355 type:image/jpeg size:1463440 hash:sha-1:\ 356 FF:27:0D:81:14:F1:8A:C3:35:3B:36:64:2A:62:C9:3E:D3:6B:51:B4 357 a=dcsa:2 file-transfer-id:rjEtHAcYVZ7xKwGYpGGwyn5gqsSaU7Ep 358 a=dcsa:2 file-disposition:attachment 359 a=dcsa:2 file-date:creation:"Mon, 12 Jan 2018 15:01:31 +0800" 360 a=dcsa:2 file-icon:cid:id2@bob.example.com 361 a=dcsa:2 file-range:1-1463440 363 5.1.2. Session Opening 365 Section 5.1.1.3 describes how the active MSRP session endpoint role 366 is negotiated. The active MSRP session endpoint uses the data 367 channel established for this MSRP session by the generic data channel 368 opening procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 369 The path attribute SHALL NOT be used for transport negotiation. 371 As soon as this data channel is opened, the MSRP session is actually 372 opened by the active MSRP session endpoint. In order to do this the 373 active MSRP endpoint sends an MSRP SEND message (empty or not) to the 374 other MSRP endpoint. 376 5.1.3. Data Framing 378 Each text-based MSRP message is sent on the corresponding SCTP stream 379 using standard MSRP framing and chunking procedures, as defined in 380 [RFC4975], with each MSRP chunk delivered in a single SCTP user 381 message. Therefore all sent MSRP chunks including the MSRP chunk 382 header MUST have lengths of less than or equal to the value of the 383 peer's "a=max-message-size" attribute, which is associated with the 384 data channel's SCTP association. 386 5.1.4. Data Sending and Reporting 388 Data sending and reporting procedures SHALL conform to RFC 4975. 390 5.1.5. Session Closing 392 The closure of an MSRP session MUST be signaled via an SDP offer/ 393 answer exchange which removes the "a=dcmap:" and "a=dcsa:" attribute 394 lines associated with the MSRP session from the associated DTLS/SCTP 395 based media description. This results in the associated data channel 396 being closed as well as per [I-D.ietf-mmusic-data-channel-sdpneg], 397 where the actual data channel closure procedure is typically 398 initiated by the SDP answerer right after having accepted the SDP 399 offer. 401 The port value for the "m" line SHOULD NOT be changed (e.g. to zero) 402 when closing an MSRP session (unless all data channels are being 403 closed and the SCTP association is no longer needed), since this 404 would close the SCTP association and impact all of the data channels. 405 In all cases in [RFC4975] where the procedure calls for setting the 406 port to zero for the MSRP "m" line in an SDP offer for TCP transport, 407 the SDP offerer of an MSRP session with data channel transport SHALL 408 remove the corresponding dcmap and dcsa attributes. 410 The SDP answerer must ensure that no dcmap or dcsa attributes are 411 present in the SDP answer if no corresponding attributes are present 412 in the received SDP offer. 414 5.2. Support for MSRP File Transfer Function 416 [RFC5547] defines an end-to-end file transfer method based on MSRP 417 and the SDP offer/answer mechanism. This file transfer method is 418 also usable by MSRP endpoints using data channels, with the following 419 considerations: 421 o As an MSRP session maps to one data channel, a file transfer 422 session maps also to one data channel. 424 o SDP attributes specified in [RFC5547] for a file transfer "m" line 425 are embedded as subprotocol-specific attributes using the syntax 426 defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 428 o Once the file transfer is complete, the same data channel MAY be 429 reused for another file transfer. 431 6. Gateway Configuration 433 This section describes the network configuration where one MSRP 434 endpoint uses data channels as MSRP transport, the other MSRP 435 endpoint uses TLS/TCP connections as MSRP transport, and the two MSRP 436 endpoints interwork via an MSRP gateway. 438 Specifically, a gateway can be configured to interwork an MSRP 439 session over a data channel with a peer that does not support data 440 channel transport in one of two ways. 442 In one model, the gateway performs as a MSRP B2BUA to interwork all 443 the procedures as necessary between the endpoints. No further 444 specification is needed for this model. 446 Alternately, the gateway can use CEMA procedures to provide transport 447 level interworking between MSRP endpoints using different transport 448 protocols as follows. For example, if the gateway is implemented on 449 an Session Border Controller, it can use CEMA towars the inside 450 network, using a non-data channel transport; but the gateway can not 451 use CEMA towards endpoints using data channel transport. Path 452 attributes SHALL NOT be used for transport level interworking. 454 When the gateway performs transport level interworking between MSRP 455 endpoints, all of the procedures in Section 5 apply to each peer, 456 with the following additions: 458 o The endpoint establishing an MSRP session using data channel 459 transport SHALL NOT request inclusion of any relays, although it 460 MAY interoperate with a peer that signals the use of relays. 462 o The gateway receiving an SDP offer that includes a request to 463 negotiate an MSRP session on a data channel can provide transport 464 level interworking by forwarding TCP or TLS transport parameters 465 in a new "m" line with the appropriate attributes within the 466 forwarded SDP offer. 468 * Especially, the gateway interworks the received MSRP over data 469 channel associated dcsa embedded setup attribute with the media 470 description level "a=setup" attribute of the MSRP over TCP or 471 TLS "m" line within its forwarded SDP offer. 473 o Similarly, a gateway receiving an SDP offer to negotiate an MSRP 474 session using TCP or TLS transport with an endpoint that only 475 supports data channel transport for MSRP can provide transport 476 level interworking by establishing a new data channel for the MSRP 477 session with the target endpoint. 479 * In this case the gateway interworks the received MSRP over TCP 480 or TLS associated "a=setup" attribute with the dcsa embedded 481 setup attribute of the generated MSRP over data channel 482 description. 484 7. IANA Considerations 486 7.1. Subprotocol Identifier MSRP 488 NOTE to RFC Editor: Please replace "XXXX" with the number of this 489 RFC. 491 This document adds the subprotocol identifier "MSRP" to the 492 "WebSocket Subprotocol Name Registry" as follows: 494 +--------------------------+---------+ 495 | Subprotocol Identifier: | MSRP | 496 | Subprotocol Common Name: | MSRP | 497 | Subprotocol Definition: | RFCXXXX | 498 | Reference: | RFCXXXX | 499 +--------------------------+---------+ 501 7.2. setup Attribute 503 NOTE to RFC Editor: Please replace "XXXX" with the number of this 504 RFC. 506 This document modifies the usage of the SDP setup attribute, if this 507 attribute is embedded in a dcsa attribute and associated with an MSRP 508 session over a data channel. The modified usage is described in 509 Section 5.1.1.3. 511 Usage level "dcsa(MSRP)" should be added to the IANA registration of 512 the SDP setup attribute as follows: 514 +-----------------------+-------------------------------------------+ 515 | Contact name: | MMUSIC Chairs | 516 | Contact email: | mmusic-chairs@ietf.org | 517 | Attribute name: | setup | 518 | Usage level: | dcsa(MSRP) | 519 | Purpose: | Negotiate the active role of an MSRP | 520 | | session over a data channel as per | 521 | | Section 5.1.1.3 | 522 | Reference: | RFCXXXX | 523 +-----------------------+-------------------------------------------+ 525 8. Security Considerations 527 MSRP traffic over data channels is secured, including 528 confidentiality, integrity and source authentication, as specified by 529 [I-D.ietf-rtcweb-data-channel] 531 Note that discussion in [RFC4975] on MSRP message attribution to 532 remote identities applies to data channel transport. 534 9. Acknowledgments 536 The authors wish to acknowledge the borrowing of ideas from another 537 internet draft by Peter Dunkley and Gavin Llewellyn, and to thank 538 Flemming Andreasen, Christian Groves, Christer Holmberg, Paul 539 Kyzivat, Jonathan Lennox, Uwe Rauschenbach, Albrecht Schwarz and 540 Keith Drage for their invaluable comments. 542 10. CHANGE LOG 544 10.1. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-11' 546 o Additional clarifications on cema and path attribute after mail 547 list feedback. 549 10.2. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-10' 551 o Corrections and clarifications on cema and path attributes after 552 mail list feedback. 554 10.3. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-09' 556 o Corrected area to ART. 558 10.4. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-08' 560 o Updated reference to 4566bis. 562 o Expanded motivation paragraphs in introduction. 564 10.5. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-07' 566 o Move security considerations after IANA considerations, following 567 RFC7322 suggested order. 569 o Update references to use xml.resource.org citation database. 571 o Reformat of the section discussing setup parameter 573 o Align examples with latest [I-D.ietf-mmusic-data-channel-sdpneg] 574 draft. 576 o Edit section 6 for clarity. 578 o Security requirements. 580 o Clarify comment on unrecognized transports and session opening. 582 o Update year, add editor. 584 10.6. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-06' 586 o Modification of Keith's address information. 588 10.7. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-05' 590 o Modification of Juergen's address information. 592 10.8. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-04' 594 o Addition of [I-D.ietf-mmusic-rfc4566bis] to list of normative 595 references. 597 o Addition of Section 7.2 as per section 8.2.4 of 598 [I-D.ietf-mmusic-rfc4566bis]. 600 10.9. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-03' 602 o Addition of IANA registration related Section 7.1. 604 10.10. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-02' 606 o Addition of "a=setup:actpass", "a=connection:new", 607 "a=fingerprint:..." and "a=dcsa:x setup=active" SDP attributes to 608 the SDP example in Section 5.1.1.4. 610 o Addition of [RFC4145] and [I-D.ietf-mmusic-sctp-sdp] to list of 611 normative references. 613 o Addition of new Section 5.1.1.3 describing how the active MSRP 614 session endpoint role is negotiated. 616 o Extension of first paragraph of Section 5.1.2 with new first 617 sentence "Section 5.1.1.3 describes how the active MSRP session 618 endpoint role is negotiated.". 620 o First sentence of second paragraph in Section 5.1.2 was "As soon 621 as this data channel is opened, the MSRP session is actually 622 opened by the active MSRP endpoint which sends an MSRP SEND 623 message (empty or not) to the other MSRP endpoint." Replacement 624 of this sentence with "As soon as this data channel is opened, the 625 MSRP session is actually opened by the active MSRP endpoint. In 626 order to do this the active MSRP endpoint sends an MSRP SEND 627 message (empty or not) to the other MSRP endpoint." 629 o Addition of setup attribute specific behavior descriptions of data 630 channel to TCP or TLS interworking gateways in Section 6. 632 10.11. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-01' 634 o In the abstract replacement of the first sentence "This document 635 specifies how the Message Session Relay Protocol (MSRP) can be 636 instantiated as a data channel sub-protocol, using the SDP offer/ 637 answer exchange-based external negotiation defined in 638 [I-D.ietf-mmusic-data-channel-sdpneg]" with "This document 639 specifies how the Message Session Relay Protocol (MSRP) can be 640 instantiated as a data channel sub-protocol, using the SDP offer/ 641 answer exchange-based generic data channel negotiation framework" 642 in order to remove the reference from the abstract text. 644 o Addition of following sentence to the second paragraph in 645 Section 1: "The MSRP protocol negotiation defined in this document 646 is based on the generic SDP offer/answer exchange based data 647 channel negotiation as specified in 648 [I-D.ietf-mmusic-data-channel-sdpneg]". 650 o In Section 4.1 replacement of sub-protocol identifier "msrp" with 651 "MSRP" in order to make this consistent with the formal 652 specification in Section 5.1.1.1. 654 o Throughout the text replacement of "shall" with "SHALL" etc where 655 appropriate as per [RFC2119]. 657 o In Section 5.1.1.1 replacement of sentence 'The max-retr, max-time 658 and ordered parameters shall not be used.' with 'Ordered and 659 reliable data channels MUST always be used, such that the "max- 660 retr" and "max-time" parameters SHALL NOT be used. If the 661 "ordered" parameter is used, then its value MUST be equal to 662 "true".'. 664 o In Section 5.1.1.1 removal of "(on default SCTP port 5000)" from 665 the sentence preceding the example "a=dcmap" attribute line. 667 o In Section 5.1.1.2 first paragraph was "The SDP offer shall also 668 include a dcsa attribute line (defined in 669 [I-D.ietf-mmusic-data-channel-sdpneg]) within the media 670 description for the SCTP association for each MSRP-specific SDP 671 attribute to be negotiated for each MSRP data channel being 672 negotiated.". Replacement of this paragraph with "The SDP offer 673 SHALL also include within the media description for the SCTP 674 association a dcsa attribute line (defined in 675 [I-D.ietf-mmusic-data-channel-sdpneg]) for each MSRP-specific SDP 676 attribute to be negotiated for each MSRP data channel being 677 negotiated.". 679 o Appended following sentence at the end of the first paragraph of 680 Section 5.1.3: "Therefore all sent MSRP chunks MUST have lengths 681 of less than or equal to the value of the peer's "a=max-message- 682 size" attribute, which is associated with the data channel's SCTP 683 association.". 685 o Addition of the previously missing colon to the "a=sctp-port" 686 attribute line in Section 5.1.1.4. 688 o In Section 5.1.5 replacement of the first paragraph "Closing of an 689 MSRP session is done using the generic data channel closing 690 procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg]." with 691 'The closure of an MSRP session MUST be signaled via an SDP offer/ 692 answer exchange which removes the "a=dcmap:" and "a=dcsa:" 693 attribute lines associated with the MSRP session from the 694 associated DTLS/SCTP based media description. This results in the 695 associated data channel being closed as well as per 696 [I-D.ietf-mmusic-data-channel-sdpneg], where the actual data 697 channel closure procedure is typically initiated by the SDP 698 answerer right after having accepted the SDP offer.'. 700 10.12. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-00' 702 o Additional reference to [I-D.ietf-mmusic-data-channel-sdpneg] in 703 list of normative references. 705 o Replacement of previous document title "MSRP over SCTP/DTLS data 706 channels" with "MSRP over Data Channels" in order to align with 707 the terminology used in [I-D.ietf-mmusic-data-channel-sdpneg]. 709 o In Section 3 "WebRTC data channel" was defined as "A bidirectional 710 channel consisting of paired SCTP outbound and inbound streams." 711 Replacement of this definition with "Data channel: A WebRTC data 712 channel as specified in [I-D.ietf-rtcweb-data-channel]", and 713 consistent usage of either "data channel" or "MSRP data channel" 714 in the remainder of the document." 716 o In the introduction replacement of references to 717 [I-D.ietf-rtcweb-data-protocol] with a reference to 718 [I-D.ietf-rtcweb-data-channel]. 720 o Consistent usage of '"m" line' in whole document as per [RFC4566]. 722 o In the gateway configuration section (Section 6) replacement of 723 the first sentence "This section describes the network 724 configuration where one endpoint runs MSRP over a WebRTC SCTP/DTLS 725 connection, the other MSRP endpoint runs MSRP over one or more 726 TLS/TCP connections, and the two endpoints interwork via an MSRP 727 gateway" with "This section describes the network configuration 728 where one MSRP endpoint uses data channels as MSRP transport, the 729 other MSRP endpoint uses TLS/TCP connections as MSRP transport, 730 and the two MSRP endpoints interwork via an MSRP gateway". 732 10.13. Changes against 'draft-ejzak-mmusic-msrp-usage-data-channel-01' 734 o Removed empty spaces after ";" in the examples' "a=dcmap" 735 attribute lines. 737 o In all examples, the "m" line proto value "DTLS/SCTP" was replaced 738 with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were 739 replaced with "a=max-message-size" attribute lines, as per draft- 740 ietf-mmusic-sctp-sdp-12. 742 10.14. Changes against '-00' 744 o Transport parameter change for MSRP to allow MSRP RFC transports. 746 o Clarification on SDP offer/answer and removing duplicated 747 procedures and refer them to draft-ejzak-mmusic-data-channel- 748 sdpneg-02. 750 11. Normative References 752 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 753 Requirement Levels", BCP 14, RFC 2119, 754 DOI 10.17487/RFC2119, March 1997, 755 . 757 [I-D.ietf-rtcweb-jsep] 758 Uberti, J., Jennings, C., and E. Rescorla, "JavaScript 759 Session Establishment Protocol", draft-ietf-rtcweb-jsep-26 760 (work in progress), February 2019. 762 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 763 with Session Description Protocol (SDP)", RFC 3264, 764 DOI 10.17487/RFC3264, June 2002, 765 . 767 [I-D.ietf-rtcweb-data-protocol] 768 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 769 Establishment Protocol", draft-ietf-rtcweb-data- 770 protocol-09 (work in progress), January 2015. 772 [I-D.ietf-rtcweb-data-channel] 773 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 774 Channels", draft-ietf-rtcweb-data-channel-13 (work in 775 progress), January 2015. 777 [I-D.ietf-mmusic-data-channel-sdpneg] 778 Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. 779 Even, "SDP-based Data Channel Negotiation", draft-ietf- 780 mmusic-data-channel-sdpneg-28 (work in progress), May 781 2019. 783 [I-D.ietf-mmusic-sctp-sdp] 784 Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, 785 "Session Description Protocol (SDP) Offer/Answer 786 Procedures For Stream Control Transmission Protocol (SCTP) 787 over Datagram Transport Layer Security (DTLS) Transport.", 788 draft-ietf-mmusic-sctp-sdp-26 (work in progress), April 789 2017. 791 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 792 the Session Description Protocol (SDP)", RFC 4145, 793 DOI 10.17487/RFC4145, September 2005, 794 . 796 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 797 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 798 July 2006, . 800 [I-D.ietf-mmusic-rfc4566bis] 801 Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: 802 Session Description Protocol", draft-ietf-mmusic- 803 rfc4566bis-37 (work in progress), August 2019. 805 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 806 "The Message Session Relay Protocol (MSRP)", RFC 4975, 807 DOI 10.17487/RFC4975, September 2007, 808 . 810 [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., 811 and P. Kyzivat, "A Session Description Protocol (SDP) 812 Offer/Answer Mechanism to Enable File Transfer", RFC 5547, 813 DOI 10.17487/RFC5547, May 2009, 814 . 816 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 817 for the Message Session Relay Protocol (MSRP)", RFC 6135, 818 DOI 10.17487/RFC6135, February 2011, 819 . 821 [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection 822 Establishment for Media Anchoring (CEMA) for the Message 823 Session Relay Protocol (MSRP)", RFC 6714, 824 DOI 10.17487/RFC6714, August 2012, 825 . 827 [RFC7977] Dunkley, P., Llewellyn, G., Pascual, V., Salgueiro, G., 828 and R. Ravindranath, "The WebSocket Protocol as a 829 Transport for the Message Session Relay Protocol (MSRP)", 830 RFC 7977, DOI 10.17487/RFC7977, September 2016, 831 . 833 Authors' Addresses 835 Keith Drage (editor) 836 Unaffiliated 838 Email: drageke@ntlworld.com 839 Maridi R. Makaraju (Raju) 840 Unaffiliated 842 Email: mmraju@gmail.com 844 Juergen Stoetzer-Bradler 845 Unaffiliated 847 Email: Juergen.S-B.ietf@email.de 849 Richard Ejzak 850 Unaffiliated 852 Email: richard.ejzak@gmail.com 854 Jerome Marcon 855 Unaffiliated 857 Jose M. Recio (editor) 858 CoSMo Software 860 Email: jose@ch3m4.com