idnits 2.17.1 draft-blau-simple-msrp-acm-02.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 374. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 385. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 392. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 398. 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 (October 17, 2008) is 5668 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2606' is defined on line 321, but no explicit reference was found in the text == Unused Reference: 'RFC3323' is defined on line 324, 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: April 20, 2009 Ericsson 6 October 17, 2008 8 An Alternative Connection Model for the Message Session Relay Protocol 9 (MSRP) 10 draft-blau-simple-msrp-acm-02.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 April 20, 2009. 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 the following ways: it uses COMEDIA for TCP connection 42 establishment, and it allows the usage of SDP in a more conventional 43 way for conveying endpoint address information. Because of this, the 44 model also allows for the usage of generic mainstream mechanisms for 45 NAT traversal, instead of using MSRP relays. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. Applicability statement . . . . . . . . . . . . . . . . . . . 4 52 4. The Alternative Connection Model for MSRP . . . . . . . . . . 4 53 4.1. COMEDIA usage . . . . . . . . . . . . . . . . . . . . . . 4 54 4.1.1. a=setup . . . . . . . . . . . . . . . . . . . . . . . 4 55 4.1.2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4.1.3. a=connection . . . . . . . . . . . . . . . . . . . . . 6 57 4.2. Transport connection addressing . . . . . . . . . . . . . 6 58 4.3. NAT keepalive . . . . . . . . . . . . . . . . . . . . . . 7 59 4.4. ICE usage . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 65 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 67 Intellectual Property and Copyright Statements . . . . . . . . . . 10 69 1. Introduction 71 MSRP [RFC4975] is designed to use MSRP relays [RFC4976] as a means 72 for NAT traversal and policy enforcement. However, in many SIP 73 networks it is often desired to deploy MSRP without the use of MSRP 74 relays, and instead use more generic NAT traversal mechanisms - such 75 as COMEDIA [RFC4145] and ICE [I.D-ietf-mmusic-ice] - while also using 76 SIP ALG controlled media relays for more application specific policy 77 control. 79 An example is the OMA defined "Instant Message using SIMPLE" [OMA-TS- 80 SIMPLE_IM-V1_0-20080312-D], where the UA of one endpoint of every 81 MSRP transport connection is a media server located in the network. 82 The media server has a global address and is handling application 83 specific policy control as well as NAT traversal, the latter through 84 use of COMEDIA which all IM MSRP clients are mandated to support. 86 Many networks where MSRP usage is emerging also contain ALGs that are 87 deployed for reasons of performance monitoring, lawful intercept, 88 address domain bridging, interconnect SLA policy enforcement, etc. A 89 typical example here is the 3GPP defined Interconnect Border Control 90 Function (IBCF) [3GPP TS23.228], which controls a media relay that 91 handles all types of SIP session media (voice, video, MSRP, etc). 92 Due to the fact that the MSRP connection model is not in a 93 conventional way using the address information in the SDP c- and 94 m-line for negotiating transport connection endpoints, and also 95 checks consistence between addresses in the MSRP protocol and in the 96 SDP a=path line, this forces the IBCF/media relay to act as an SDP 97 aware MSRP B2BUA, whereas for basically all other UDP and TCP 98 transported based media sessions it can acts as an SDP aware Relay- 99 NAPT - which is much simpler than having to act as an MSRP B2BUA. 101 To adapt MSRP to a more conventional SDP usage, which is more 102 friendly to general NAT traversal methods and to ALGs, this document 103 defines an alternative connection model for MSRP. The model differs 104 from the [RFC4975] defined model in that COMEDIA [RFC4145] is used in 105 SDP offer/answer exchanges, and that the c- and m-line address and 106 port information may be used in conventional SDP manner for 107 determining transport endpoint, meaning that the address and port 108 information in the MSRP URI in the a=path line is no longer used for 109 routing. 111 NOTE: It is possible for a UA to only use the COMEDIA mechanism of 112 the alternative connection model, but to use the MSRP routing 113 mechanism defined in [RFC4975]. 115 The alternative connection model allows conformant UAs to fall back 116 to [RFC4975] compliant behavior when interacting with [RFC4975] 117 conformant UAs. 119 2. Conventions 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in BCP 14, RFC 2119 124 [RFC2119]. 126 3. Applicability statement 128 The alternative connection model for MSRP, as defined in this 129 document, SHOULD be used when a UA does not use an MSRP relay to 130 proxy its MSRP communication. The UA SHALL use COMEDIA. If ALGs are 131 used the UA SHOULD use SDP c/m line conveyed address and port 132 information for MSRP routing, otherwise the UA MAY use the address 133 and port information conveyed in the MSRP URI (as per RFC4975). 135 UAs conformant to this document are fully interoperable with 136 [RFC4975] conformant UAs, since when interacting with such UAs they 137 will more or less fall back to [RFC4975] compliant behavior. 138 However, if a UA conformant to this document is behind NAT and 139 receives an SDP offer from an [RFC4975] conformant UA, NAT traversal 140 can only be achieved if the UA supports ICE (and the network provides 141 TURN servers) or if the network supports SBC assisted NAT traversal 142 for TCP. 144 4. The Alternative Connection Model for MSRP 146 4.1. COMEDIA usage 148 4.1.1. a=setup 150 A UA SHALL support the a=setup attribute [RFC4145], in order to 151 negotiate which endpoint is to establish the transport connection for 152 an MSRP session. 154 The support of a=setup is particularly useful when one MSRP endpoint 155 is a media server which is not behind a NAT. This since the media 156 server then make sure that transport connections for MSRP media is 157 always set up from the UA towards the server, and ensure that 158 possible NATs at user premises will not interfere with the connection 159 setup. 161 A UA SHALL always include an explicit a=setup line in SDP offers and 162 answers, since it is sometimes useful for the other endpoint, or for 163 the network, to know whether the sending endpoint supports a=setup or 164 not. 166 The a=setup "active", "actpass" and "passive" values SHALL be 167 supported, while the "holdcon" value MUST NOT be used. 169 NOTE: When the a=setup value is "actpass" or "passive", the IP 170 address:port value in the SDP MUST contain the actual address:port on 171 which the UA can receive a TCP Open request for the MSRP transport 172 connection. 174 If the a=setup value is "active", the port number value MUST either 175 be the actual port number that will be used for the TCP endpoint or 176 the port value 9. 178 The a=setup "actpass" value SHALL be used in SDP offers whenever an 179 UA can determine a valid WAN transport endpoint address:port, i.e. an 180 address:port that the other endpoint can use as destination for a TCP 181 Open request. This is in order to a) allow the other endpoint to 182 answer with "a=setup:active" if it is behind NAT, and b) to be 183 compatible with MSRP endpoints that do not support COMEDIA and thus 184 always will always act as passive endpoints. If not the actual 185 transport address can be provided then the a=setup "active" value 186 MUST be used. 188 A valid WAN transport address:port can be determined if the UA can 189 determine that it is not located behind a NAT, or if the UA relays 190 its MSRP transport connections via a TURN server, or if it through 191 STUN signaling from the local port to be used for the eventual 192 transport connection has used STUN to retrieve NAT address:port while 193 also having determined that the NAT is not address restricted. 195 If the UA is located behind a NAT, both SIP signaling and media 196 transport will pass trough it, and a UA can determine whether the 197 media transport will be NATed by inspecting the SIP Via header in the 198 200 OK response to the initial REGISTER request, comparing the IP 199 addresses in the Via sent-by and received parameters. If these are 200 not the same then there is a NAT in the path. 202 If an SDP offer includes a=setup:actpass, the SDP answer MAY include 203 a=setup:active, but SHOULD include a=setup:passive if the SDP 204 answerer knows that it is not located behind a NAT. 206 4.1.2. TLS 208 If a TLS transport connection for MSRP is negotiated, the client and 209 server TLS roles MUST negotiate the relevant parameter as specified 210 by COMEDIA-TLS [RFC4572], and in accordance with [RFC4975] the MSRP 211 URI scheme SHOULD be msrps and the m-line protocol indicator SHOULD 212 be TCP/TLS/MSRP. 214 4.1.3. a=connection 216 The a=connection attribute is defined as a means for SDP negotiation 217 of transport connection reuse. However, it seems that its use is 218 limited to mid-session SDP offer/answer exchanges while [RFC4976] 219 requires initial SDP offer/answer exchanges to result in reuse of a 220 transport connection established via another existing SIP session at 221 the same UA, if the SDP for the remote endpoint of that connection 222 indicates the same host address, port and URI scheme. 224 A UA SHALL use a=connection lines for mid-session re-negotiation of 225 transport connection for an MSRP session, but SHOULD not include any 226 a=connection line in initial SDP offer/answer exchanges (if present, 227 it SHALL be ignored by the receiving UA). Instead the connection 228 reuse principles for initial SDP offer/answer exchanges for an MSRP 229 session SHALL be in accordance with [RFC4975]. 231 4.2. Transport connection addressing 233 If the UA supports the transport connection addressing mechanism 234 defined in this chapter, the UA shall follow the procedures described 235 below. 237 The UA SHALL follow the conventional use of address information 238 received in the SDP c- and m-lines for determining the transport 239 connection endpoint address:port to connect to, instead of using the 240 address information in the MSRP URI received in the a=path line to 241 determine the remote transport connection endpoint address:port. 243 With such usage, applying COMEDIA, ICE and TLS in SDP offer/answer 244 exchanges for MSRP sessions can be done in a conventional way with 245 very little MSRP dependencies, as detailed in this document. 246 Furthermore, this usage also allows any ALG/SBC in the SIP signaling 247 path to perform media anchoring in the same way they today do for any 248 TCP connections not used for MSRP, i.e. by modifying the address:port 249 information in the c- and m-lines, and ignoring any a=path line. 251 When a UA sends an SDP offer, the MSRP URI in the a=path line of the 252 SDP offer (and eventually in the MSRP FromPath header) MAY include an 253 AoR instead of connection address information. The AoR usage works 254 fine even if the SDP answerer is a [RFC4975] conformant UA, since in 255 such cases the SDP offerer will always establish the transport 256 connection based on address information in the SDP answer. The MSRP 257 URI matching will still work since this only requires the MSRP URIs 258 in the a=path headers to be identical to the MSRP URIs in the MSRP 259 protocol FromPath and ToPath headers. 261 When a UA sends an SDP offer, the UA SHALL include an "a=msrp-acm" 262 attribute, which indicates that the UA supports the transport 263 connection addressing defined in this specifciation. 265 When a UA receives an SDP offer which contains an "a=msrp-acm" 266 attribute, the UA SHALL include the attribute in the SDP answer. 268 When a UA receives an SDP offer from an [RFC4975] conformant UA (the 269 receiving UA knows this if the SDP offer does not contain an 270 "a=setup" attribute), or the UA receives an SDP offer from a UA which 271 only supports the COMEDIA usage mechanism of this specification (the 272 receiving UA knows this if the SDP offer does not contain an "a=msrp- 273 acm" attribute), the UA needs to populate the MSRP URI in the SDP 274 answer (and eventually in the MSRP FromPath header) with an address 275 or FQDN in accordance with [RFC4975]. 277 In accordance with [RFC4975], for an MSRP endpoint that receives TCP 278 open requests to be able to use a common port for all MSRP transport 279 connections, the initiator of an MSRP transport connection SHALL 280 always after having established a new transport connection send an 281 MSRP message, allowing the other endpoint to establish the binding 282 between MSRP session and transport connection. 284 4.3. NAT keepalive 286 An MSRP endpoint behind NAT MUST keep the NAT binding alive, in 287 accordance with chapter 10 in [I.D.ietf-mmusic-ice]. The character 288 string CRLF SHOULD be sent as NAT keepalive, but if the transport 289 connection was established using ICE then STUN MAY alternatively be 290 used. 292 4.4. ICE usage 294 If the UA is using ICE for MSRP transport connection establishment, 295 it SHALL before starting to send any TCP Open requests perform the 296 normal MSRP checks for possible reuse of an existing transport 297 connection. If such is identified, the UA SHOULD preempt ICE 298 processing and send a new SIP offer which indicates a=connection: 299 existing and the SDP information for the selected connection. 301 5. Security Considerations 303 TBD 305 6. IANA Considerations 307 This document declares a new SDP attribute, "a=msrp-acm". 309 7. Acknowledgements 311 Thanks to Hadriel Kaplan and Remi Denis-Courmont for their comments 312 and input on this document. 314 8. References 316 8.1. Normative References 318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 319 Requirement Levels", BCP 14, RFC 2119, March 1997. 321 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 322 Names", BCP 32, RFC 2606, June 1999. 324 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 325 Initiation Protocol (SIP)", RFC 3323, November 2002. 327 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 328 the Session Description Protocol (SDP)", RFC 4145, 329 September 2005. 331 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 332 Transport Layer Security (TLS) Protocol in the Session 333 Description Protocol (SDP)", RFC 4572, July 2006. 335 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 336 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 338 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 339 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 340 September 2007. 342 8.2. Informative References 343 Authors' Addresses 345 Staffan Blau 346 Ericsson AB 347 P.O Box 407 348 Sweden 350 Email: staffan.blau@ericsson.com 352 Christer Holmberg 353 Ericsson 354 Hirsalantie 11 355 Jorvas 02420 356 Finland 358 Email: christer.holmberg@ericsson.com 360 Full Copyright Statement 362 Copyright (C) The IETF Trust (2008). 364 This document is subject to the rights, licenses and restrictions 365 contained in BCP 78, and except as set forth therein, the authors 366 retain all their rights. 368 This document and the information contained herein are provided on an 369 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 370 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 371 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 372 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 373 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 374 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 376 Intellectual Property 378 The IETF takes no position regarding the validity or scope of any 379 Intellectual Property Rights or other rights that might be claimed to 380 pertain to the implementation or use of the technology described in 381 this document or the extent to which any license under such rights 382 might or might not be available; nor does it represent that it has 383 made any independent effort to identify any such rights. Information 384 on the procedures with respect to rights in RFC documents can be 385 found in BCP 78 and BCP 79. 387 Copies of IPR disclosures made to the IETF Secretariat and any 388 assurances of licenses to be made available, or the result of an 389 attempt made to obtain a general license or permission for the use of 390 such proprietary rights by implementers or users of this 391 specification can be obtained from the IETF on-line IPR repository at 392 http://www.ietf.org/ipr. 394 The IETF invites any interested party to bring to its attention any 395 copyrights, patents or patent applications, or other proprietary 396 rights that may cover technology that may be required to implement 397 this standard. Please address the information to the IETF at 398 ietf-ipr@ietf.org.