idnits 2.17.1 draft-blau-simple-msrp-acm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 388. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 399. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 412. 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 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: A UA SHALL use a=connection lines for mid-session re-negotiation of transport connection for an MSRP session, but SHOULD not include any a=connection line in initial SDP offer/answer exchanges (if present, it SHALL be ignored by the receiving UA). Instead the connection reuse principles for initial SDP offer/answer exchanges for an MSRP session SHALL be in accordance with [RFC4975]. -- 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 (June 25, 2008) is 5777 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2606' is defined on line 334, but no explicit reference was found in the text == Unused Reference: 'RFC3323' is defined on line 337, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4572 (Obsoleted by RFC 8122) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE Working Group S. Blau 3 Internet-Draft Ericsson AB 4 Intended status: Informational C. Holmberg 5 Expires: December 27, 2008 Ericsson 6 June 25, 2008 8 An Alternative Connection Model for the Message Session Relay Protocol 9 (MSRP) 10 draft-blau-simple-msrp-acm-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 27, 2008. 37 Abstract 39 This document defines an alternative connection model for MSRP UAs. 40 The model differs from the standard MSRP model, as defined in RFC4975 41 and RFC4976, in that it uses SDP in a more conventional way when it 42 comes to conveying endpoint address information, and also uses 43 mainstream mechanisms for NAT traversal instead of using MSRP relays. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Applicability statement . . . . . . . . . . . . . . . . . . . 4 50 4. The Alternative Connection Model for MSRP . . . . . . . . . . 4 51 4.1. Transport connection addressing . . . . . . . . . . . . . 4 52 4.2. COMEDIA usage . . . . . . . . . . . . . . . . . . . . . . 5 53 4.2.1. a=setup . . . . . . . . . . . . . . . . . . . . . . . 5 54 4.2.2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 4.2.3. a=connection . . . . . . . . . . . . . . . . . . . . . 6 56 4.3. NAT keepalive . . . . . . . . . . . . . . . . . . . . . . 7 57 4.4. ICE usage . . . . . . . . . . . . . . . . . . . . . . . . 7 58 5. Comparisons with draft-denis-simple-msrp-comedia . . . . . . . 7 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 64 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 66 Intellectual Property and Copyright Statements . . . . . . . . . . 10 68 1. Introduction 70 MSRP [RFC4975] is designed to use MSRP relays [RFC4976] as a means 71 for NAT traversal and policy enforcement. However, in many SIP 72 networks it is often desired to deploy MSRP without the use of MSRP 73 relays, and instead use more general NAT traversal mechanisms - such 74 as COMEDIA [RFC4145] and ICE [I.D-ietf-mmusic-ice] - while also using 75 SIP ALG controlled media relays for more application specific policy 76 control. 78 An example is the OMA defined "Instant Message using SIMPLE" [OMA-TS- 79 SIMPLE_IM-V1_0-20080312-D], where the UA of one endpoint of every 80 MSRP transport connection is a media server located in the network. 81 The media server has a global address and is handling application 82 specific policy control as well as NAT traversal, the latter through 83 use of COMEDIA which all IM MSRP clients are mandated to support. 85 Many networks where MSRP usage is emerging also contain ALGs that are 86 deployed for reasons of performance monitoring, lawful intercept, 87 address domain bridging, interconnect SLA policy enforcement, etc. A 88 typical example here is the 3GPP defined Interconnect Border Control 89 Function (IBCF) [3GPP TS23.228], which controls a media relay that 90 handles all types of SIP session media (voice, video, MSRP, etc). 91 Due to the fact that the MSRP connection model is not in a 92 conventional way using the address information in the SDP c- and 93 m-line for negotiating transport connection endpoints, and also 94 checks consistence between addresses in the MSRP protocol and in the 95 SDP a=path line, this forces the IBCF/media relay to act as an SDP 96 aware MSRP B2BUA, whereas for basically all other UDP and TCP 97 transported based media sessions it can acts as an SDP aware Relay- 98 NAPT - which is much simpler than having to act as an MSRP B2BUA. 100 To adapt MSRP to a more conventional SDP usage, this document defines 101 an alternative connection model for MSRP, mandating and detailing use 102 of COMEDIA [RFC4145] and optional use of ICE [I-D.ietf-mmusic-ice- 103 tcp], and use of SDP c- and m-line address information for transport 104 connection set up - instead of address information in the MSRP URI in 105 the a=path line. 107 The alternative connection model defined in this document also 108 includes mechanisms that makes UAs conformant to this document to be 109 able to use [RFC4975] compliant behavior when so needed for 110 interacting with [RFC4975] conformant UAs. 112 2. Conventions 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in BCP 14, RFC 2119 117 [RFC2119]. 119 3. Applicability statement 121 The alternative connection model for MSRP, as defined in this 122 document, SHOULD be used when a UA does not use an MSRP relay to 123 proxy its MSRP communication. 125 UAs conformant to this document are fully interoperable with 126 [RFC4975] conformant UAs, since when interacting with such UAs they 127 will more or less fall back to [RFC4975] compliant behavior. 128 However, if a UA conformant to this document is behind NAT and 129 receives an SDP offer from an [RFC4975] conformant UA, NAT traversal 130 can only be achieved if the UA supports ICE (and the network provides 131 TURN servers) or if the network supports SBC assisted NAT traversal 132 for TCP. 134 4. The Alternative Connection Model for MSRP 136 4.1. Transport connection addressing 138 A UA SHALL follow the conventional use of address information 139 received in the SDP c- and m-lines, for determining the transport 140 connection endpoint address:port to connect to, instead of using the 141 address information in the MSRP URI received in the a=path line to 142 determine the remote transport connection endpoint address:port. 144 With such usage, applying COMEDIA and ICE and TLS in SDP offer/answer 145 exchanges for MSRP sessions can be done more or less in the 146 conventional way with very little MSRP dependencies, as detailed in 147 this document. Furthermore, this usage also allows any ALG/SBC in 148 the SIP signaling path to perform media anchoring in the same way 149 they today do for any TCP connections not used for MSRP, i.e. by 150 modifying the address:port information in the c- and m-lines, and 151 ignoring any a=path line. 153 When a UA sends an SDP offer, the MSRP URI in the a=path line of the 154 SDP offer (and eventually in the MSRP FromPath header) does not need 155 to include connection address information, it is recommended to 156 instead include an AoR to avoid the possibility to use it for address 157 resolution - the AoR may be useful for debugging purposes only. 159 The usage of an AoR in the MSRP URI should work fine in SDP offers, 160 even if the SDP answerer UA is conformant to [RFC4975], since in that 161 case it will always be the SDP offerer that will establish the 162 transport connection based on address information in the SDP answer - 163 the MSRP URI matching will still work since this only requires the 164 MSRP URIs in the a=path headers to be identical to the MSRP URIs in 165 the MSRP protocol FromPath and ToPath headers. 167 When a UA receives an SDP offer from an [RFC4975] conformant UE, it 168 needs to populate the MSRP URI in the SDP answer (and eventually in 169 the MSRP FromPath header) with an address or FQDN in accordance with 170 [RFC4975]. In order for the SDP answerer to know whether this is 171 necessary or not, a UA conformant to this document SHALL include, in 172 SDP offers and answers, an "a=msrp-acm" attribute. The presence of 173 the attribute will also enable ALGs/SBCs to apply normal media 174 anchoring procedures and need not act as MSRP B2BUAs. 176 In accordance with [RFC4975], for an MSRP endpoint that receives TCP 177 open requests to be able to use a common port for all MSRP transport 178 connections, the initiator of an MSRP transport connection SHALL 179 always after having established a new transport connection send an 180 MSRP message, allowing the other endpoint to establish the binding 181 between MSRP session and transport connection. 183 4.2. COMEDIA usage 185 4.2.1. a=setup 187 A UA SHALL support the a=setup attribute [RFC4145], in order to 188 negotiate which endpoint is to establish the transport connection for 189 an MSRP session. 191 The support of a=setup is particularly useful when one MSRP endpoint 192 is a media server which is not behind a NAT. This since the media 193 server then make sure that transport connections for MSRP media is 194 always set up from the UA towards the server, and ensure that 195 possible NATs at user premises will not interfere with the connection 196 setup. 198 A UA SHALL always include an explicit a=setup line in SDP offers and 199 answers, since it is sometimes useful for the other endpoint, or for 200 the network, to know whether the sending endpoint supports a=setup or 201 not. 203 The a=setup "active", "actpass" and "passive" values SHALL be 204 supported, while the "holdcon" value MUST NOT be used. 206 Note: When the a=setup value is "actpass" or "passive", the IP 207 address:port value in the SDP MUST contain the actual address:port on 208 which the UA can receive a TCP Open request for the MSRP transport 209 connection. 211 If the a=setup value is "active", the port number value MUST either 212 be the actual port number that will be used for the TCP endpoint or 213 the port value 9. 215 The a=setup "actpass" value SHALL be used in SDP offers whenever an 216 UA can determine a valid WAN transport endpoint address:port, i.e. an 217 address:port that the other endpoint can use as destination for a TCP 218 Open request. This is in order to a) allow the other endpoint to 219 answer with "a=setup:active" if it is behind NAT, and b) to be 220 compatible with MSRP endpoints that do not support COMEDIA and thus 221 always will always act as passive endpoints. If not the actual 222 transport address can be provided then the a=setup "active" value 223 MUST be used. 225 A valid WAN transport address:port can be determined if the UA can 226 determine that it is not located behind a NAT, or if the UA relays 227 its MSRP transport connections via a TURN server, or if it through 228 STUN signaling from the local port to be used for the eventual 229 transport connection has used STUN to retrieve NAT address:port while 230 also having determined that the NAT is not address restricted. 232 If the UA is located behind a NAT, both SIP signaling and media 233 transport will pass trough it, and a UA can determine whether the 234 media transport will be NATed by inspecting the SIP Via header in the 235 200 OK response to the initial REGISTER request, comparing the IP 236 addresses in the Via sent-by and received parameters. If these are 237 not the same then there is a NAT in the path. 239 If an SDP offer includes a=setup:actpass, the SDP answer MAY include 240 a=setup:active, but SHOULD include a=setup:passive if the SDP 241 answerer knows that it is not located behind a NAT. 243 4.2.2. TLS 245 If a TLS transport connection for MSRP is negotiated, the client and 246 server TLS roles MUST negotiate the relevant parameter as specified 247 by COMEDIA-TLS [RFC4572], and in accordance with [RFC4975] the MSRP 248 URI scheme SHOULD be msrps and the m-line protocol indicator SHOULD 249 be TCP/TLS/MSRP. 251 4.2.3. a=connection 253 The a=connection attribute is defined as a means for SDP negotiation 254 of transport connection reuse. However, it seems that its use is 255 limited to mid-session SDP offer/answer exchanges while [RFC4976] 256 requires initial SDP offer/answer exchanges to result in reuse of a 257 transport connection established via another existing SIP session at 258 the same UA, if the SDP for the remote endpoint of that connection 259 indicates the same host address, port and URI scheme. 261 A UA SHALL use a=connection lines for mid-session re-negotiation of 262 transport connection for an MSRP session, but SHOULD not include any 263 a=connection line in initial SDP offer/answer exchanges (if present, 264 it SHALL be ignored by the receiving UA). Instead the connection 265 reuse principles for initial SDP offer/answer exchanges for an MSRP 266 session SHALL be in accordance with [RFC4975]. 268 4.3. NAT keepalive 270 An MSRP endpoint behind NAT MUST keep the NAT binding alive, in 271 accordance with chapter 10 in [I.D.ietf-mmusic-ice]. The character 272 string CRLF SHOULD be sent as NAT keepalive, but if the transport 273 connection was established using ICE then STUN MAY alternatively be 274 used. 276 4.4. ICE usage 278 A UA SHOULD support ICE [I.D.draft-ietf-mmusic-ice-tcp]. However, 279 the UA SHALL when using ICE for MSRP transport connection 280 establishment before starting to send any TCP Open requests perform 281 the normal MSRP checks for possible reuse of an existing transport 282 connection. If such is identified, the UA SHOULD preempt ICE 283 processing and send a new SIP offer which indicates a=connection: 284 existing and the SDP information for the selected connection. 286 5. Comparisons with draft-denis-simple-msrp-comedia 288 The denis draft extends MSRP SDP with COMEDIA in much the same way as 289 described in this document, but is somewhat looser in how COMEDIA can 290 be used. It does not for example mandate the usage of port 9 in SDP 291 if not a valid receive port is indicated and it allows a UA that is 292 not behind NAT to send an offer with a=setup:passive as an 293 alternative to a=setup:actpass. 295 The major differences between this draft and the denis draft, 296 however, is that the denis draft: 298 - only provides means for NAT traversal when there is a NAT only in 299 front of one endpoint. 301 - does not mention that for COMEDIA to be able to be used as a means 302 for NAT traversal the UA must also support sending NAT keepalives. 304 - does not discuss the a=connection attribute in relation to MSRP 305 transport connection reuse between different SIP sessions 307 - does not describe how ICE could be used for MSRP connection 308 establishment (it does refer to an expired draft on this issue) 310 - maintains the [RFC4975] model, using the MSRP URI for addressing 311 purposes, which means that any procedures dependent on address 312 information in SDP need to be special for MSRP, and any SBC in the 313 session path must act as SDP aware MSRP B2BUAs. 315 6. Security Considerations 317 TBD 319 7. IANA Considerations 321 This document declares a new SDP attribute, "a=msrp-acm". 323 8. Acknowledgements 325 Thanks to Hadriel Kaplan for his comments. 327 9. References 329 9.1. Normative References 331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 332 Requirement Levels", BCP 14, RFC 2119, March 1997. 334 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 335 Names", BCP 32, RFC 2606, June 1999. 337 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 338 Initiation Protocol (SIP)", RFC 3323, November 2002. 340 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 341 the Session Description Protocol (SDP)", RFC 4145, 342 September 2005. 344 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 345 Transport Layer Security (TLS) Protocol in the Session 346 Description Protocol (SDP)", RFC 4572, July 2006. 348 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 349 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 351 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 352 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 353 September 2007. 355 9.2. Informative References 357 Authors' Addresses 359 Staffan Blau 360 Ericsson AB 361 P.O Box 407 362 Sweden 364 Email: staffan.blau@ericsson.com 366 Christer Holmberg 367 Ericsson 368 Hirsalantie 11 369 Jorvas 02420 370 Finland 372 Email: christer.holmberg@ericsson.com 374 Full Copyright Statement 376 Copyright (C) The IETF Trust (2008). 378 This document is subject to the rights, licenses and restrictions 379 contained in BCP 78, and except as set forth therein, the authors 380 retain all their rights. 382 This document and the information contained herein are provided on an 383 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 384 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 385 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 386 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 387 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 388 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 390 Intellectual Property 392 The IETF takes no position regarding the validity or scope of any 393 Intellectual Property Rights or other rights that might be claimed to 394 pertain to the implementation or use of the technology described in 395 this document or the extent to which any license under such rights 396 might or might not be available; nor does it represent that it has 397 made any independent effort to identify any such rights. Information 398 on the procedures with respect to rights in RFC documents can be 399 found in BCP 78 and BCP 79. 401 Copies of IPR disclosures made to the IETF Secretariat and any 402 assurances of licenses to be made available, or the result of an 403 attempt made to obtain a general license or permission for the use of 404 such proprietary rights by implementers or users of this 405 specification can be obtained from the IETF on-line IPR repository at 406 http://www.ietf.org/ipr. 408 The IETF invites any interested party to bring to its attention any 409 copyrights, patents or patent applications, or other proprietary 410 rights that may cover technology that may be required to implement 411 this standard. Please address the information to the IETF at 412 ietf-ipr@ietf.org.