idnits 2.17.1 draft-ietf-simple-msrp-acm-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 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 date (August 10, 2009) is 5371 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) == Unused Reference: 'RFC2606' is defined on line 352, but no explicit reference was found in the text == Unused Reference: 'RFC3323' is defined on line 355, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4572 (Obsoleted by RFC 8122) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Expires: February 11, 2010 S. Blau 5 Ericsson AB 6 August 10, 2009 8 An Alternative Connection Model for the Message Session Relay Protocol 9 (MSRP) 10 draft-ietf-simple-msrp-acm-01.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on February 11, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document defines an alternative connection model for MSRP UAs. 50 The model differs from the standard MSRP model, as defined in RFC4975 51 and RFC4976 in the following ways: it uses COMEDIA for TCP connection 52 establishment, and it allows the usage of SDP in a more conventional 53 way for conveying endpoint address information. Because of this, the 54 model also allows for the usage of generic mainstream mechanisms for 55 NAT traversal, instead of using MSRP relays. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Applicability statement . . . . . . . . . . . . . . . . . . . . 4 62 4. The Alternative Connection Model for MSRP . . . . . . . . . . . 4 63 4.1. COMEDIA usage . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.1.1. a=setup . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4.1.2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1.3. a=connection . . . . . . . . . . . . . . . . . . . . . 6 67 4.1.4. MSRP relay connection . . . . . . . . . . . . . . . . . 6 68 4.2. Transport connection addressing . . . . . . . . . . . . . . 6 69 4.3. NAT keepalive . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.4. ICE usage . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 MSRP [RFC4975] is designed to use MSRP relays [RFC4976] as a means 82 for NAT traversal and policy enforcement. However, in many SIP 83 networks it is often desired to deploy MSRP without the use of MSRP 84 relays, and instead use more generic NAT traversal mechanisms - such 85 as COMEDIA [RFC4145] and ICE [I.D-ietf-mmusic-ice] - while also using 86 SIP ALG controlled media relays for more application specific policy 87 control. 89 An example is the OMA defined "Instant Message using SIMPLE" [OMA-TS- 90 SIMPLE_IM-V1_0-20080312-D], where the UA of one endpoint of every 91 MSRP transport connection is a media server located in the network. 92 The media server has a global address and is handling application 93 specific policy control as well as NAT traversal, the latter through 94 use of COMEDIA which all IM MSRP clients are mandated to support. 96 Many networks where MSRP usage is emerging also contain ALGs that are 97 deployed for reasons of performance monitoring, lawful intercept, 98 address domain bridging, interconnect SLA policy enforcement, etc. A 99 typical example here is the 3GPP defined Interconnect Border Control 100 Function (IBCF) [3GPP TS23.228], which controls a media relay that 101 handles all types of SIP session media (voice, video, MSRP, etc). 102 Due to the fact that the MSRP connection model is not in a 103 conventional way using the address information in the SDP c- and 104 m-line for negotiating transport connection endpoints, and also 105 checks consistence between addresses in the MSRP protocol and in the 106 SDP a=path line, this forces the IBCF/media relay to act as an SDP 107 aware MSRP B2BUA, whereas for basically all other UDP and TCP 108 transported based media sessions it can acts as an SDP aware Relay- 109 NAPT - which is much simpler than having to act as an MSRP B2BUA. 111 To adapt MSRP to a more conventional SDP usage, which is more 112 friendly to general NAT traversal methods and to ALGs, this document 113 defines an alternative connection model for MSRP. The model differs 114 from the [RFC4975] defined model in that COMEDIA [RFC4145] is used in 115 SDP offer/answer exchanges, and that the c- and m-line address and 116 port information may be used in conventional SDP manner for 117 determining transport endpoint, meaning that the address and port 118 information in the MSRP URI in the a=path line is no longer used for 119 routing. 121 NOTE: It is possible for a UA to only use the COMEDIA mechanism of 122 the alternative connection model, but to use the MSRP routing 123 mechanism defined in [RFC4975]. 125 The alternative connection model allows conformant UAs to fall back 126 to [RFC4975] compliant behavior when interacting with [RFC4975] 127 conformant UAs. 129 2. Conventions 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in BCP 14, RFC 2119 134 [RFC2119]. 136 3. Applicability statement 138 The alternative connection model for MSRP, as defined in this 139 document, SHOULD be used when a UA does not use an MSRP relay to 140 proxy its MSRP communication. The UA SHALL use COMEDIA. If ALGs are 141 used the UA SHOULD use SDP c/m line conveyed address and port 142 information for MSRP routing, otherwise the UA MAY use the address 143 and port information conveyed in the MSRP URI (as per RFC4975). 145 UAs conformant to this document are fully interoperable with 146 [RFC4975] conformant UAs, since when interacting with such UAs they 147 will more or less fall back to [RFC4975] compliant behavior. 148 However, if a UA conformant to this document is behind NAT and 149 receives an SDP offer from an [RFC4975] conformant UA, NAT traversal 150 can only be achieved if the UA supports ICE (and the network provides 151 TURN servers) or if the network supports SBC assisted NAT traversal 152 for TCP. 154 4. The Alternative Connection Model for MSRP 156 4.1. COMEDIA usage 158 4.1.1. a=setup 160 A UA SHALL support the a=setup attribute [RFC4145], in order to 161 negotiate which endpoint is to establish the transport connection for 162 an MSRP session. 164 The support of a=setup is particularly useful when one MSRP endpoint 165 is a media server which is not behind a NAT. This since the media 166 server then make sure that transport connections for MSRP media is 167 always set up from the UA towards the server, and ensure that 168 possible NATs at user premises will not interfere with the connection 169 setup. 171 A UA SHALL always include an explicit a=setup line in SDP offers and 172 answers, since it is sometimes useful for the other endpoint, or for 173 the network, to know whether the sending endpoint supports a=setup or 174 not. 176 The a=setup "active", "actpass" and "passive" values SHALL be 177 supported, while the "holdcon" value MUST NOT be used. 179 NOTE: When the a=setup value is "actpass" or "passive", the IP 180 address:port value in the SDP MUST contain the actual address:port on 181 which the UA can receive a TCP Open request for the MSRP transport 182 connection. 184 If the a=setup value is "active", the port number value MUST either 185 be the actual port number that will be used for the TCP endpoint or 186 the port value 9. 188 The a=setup "actpass" value SHALL be used in SDP offers whenever an 189 UA can determine a valid WAN transport endpoint address:port, i.e. an 190 address:port that the other endpoint can use as destination for a TCP 191 Open request. This is in order to a) allow the other endpoint to 192 answer with "a=setup:active" if it is behind NAT, and b) to be 193 compatible with MSRP endpoints that do not support COMEDIA and thus 194 always will always act as passive endpoints. If not the actual 195 transport address can be provided then the a=setup "active" value 196 MUST be used. 198 A valid WAN transport address:port can be determined if the UA can 199 determine that it is not located behind a NAT, or if the UA relays 200 its MSRP transport connections via a TURN server, or if it through 201 STUN signaling from the local port to be used for the eventual 202 transport connection has used STUN to retrieve NAT address:port while 203 also having determined that the NAT is not address restricted. 205 If the UA is located behind a NAT, both SIP signaling and media 206 transport will pass trough it, and a UA can determine whether the 207 media transport will be NATed by inspecting the SIP Via header in the 208 200 OK response to the initial REGISTER request, comparing the IP 209 addresses in the Via sent-by and received parameters. If these are 210 not the same then there is a NAT in the path. 212 If an SDP offer includes a=setup:actpass, the SDP answer MAY include 213 a=setup:active, but SHOULD include a=setup:passive if the SDP 214 answerer knows that it is not located behind a NAT. 216 Once the connection has been established, the active UA MUST 217 immediately send a SEND request, as defined in [RFC4975]. 219 NOTE: According to [RFC4975] the initiating UA is always active, but 220 When comedia is used the a=setup attribute is used to negotiate which 221 UA becomes active. 223 4.1.2. TLS 225 If a TLS transport connection for MSRP is negotiated, the client and 226 server TLS roles MUST negotiate the relevant parameter as specified 227 by COMEDIA-TLS [RFC4572], and in accordance with [RFC4975] the MSRP 228 URI scheme SHOULD be msrps and the m-line protocol indicator SHOULD 229 be TCP/TLS/MSRP. 231 4.1.3. a=connection 233 The a=connection attribute is defined as a means for SDP negotiation 234 of transport connection reuse. However, it seems that its use is 235 limited to mid-session SDP offer/answer exchanges while [RFC4976] 236 requires initial SDP offer/answer exchanges to result in reuse of a 237 transport connection established via another existing SIP session at 238 the same UA, if the SDP for the remote endpoint of that connection 239 indicates the same host address, port and URI scheme. 241 A UA SHALL use a=connection lines for mid-session re-negotiation of 242 transport connection for an MSRP session, but SHOULD not include any 243 a=connection line in initial SDP offer/answer exchanges (if present, 244 it SHALL be ignored by the receiving UA). Instead the connection 245 reuse principles for initial SDP offer/answer exchanges for an MSRP 246 session SHALL be in accordance with [RFC4975]. 248 OPEN ISSUE: It is FFS whether there is a need for the a=connection 249 attribute, or whether the existing MSRP connection re-use mechanism 250 can be applied. 252 4.1.4. MSRP relay connection 254 When MSRP relays [RFC4976] are used, the UA establishes a TCP 255 connection towards its relay. If the UA is located behind a MSRP 256 relay, it shall always create a connection towards the relay, no 257 matter what value the client has provided in the a=setup attribute. 259 NOTE: Even if a UA establishes a TCP connection towards its relay, 260 the UA will only send a SEND request if the UA is active. 262 4.2. Transport connection addressing 264 If the UA supports the transport connection addressing mechanism 265 defined in this chapter, the UA shall follow the procedures described 266 below. 268 The UA SHALL follow the conventional use of address information 269 received in the SDP c- and m-lines for determining the transport 270 connection endpoint address:port to connect to, instead of using the 271 address information in the MSRP URI received in the a=path line to 272 determine the remote transport connection endpoint address:port. 274 With such usage, applying COMEDIA, ICE and TLS in SDP offer/answer 275 exchanges for MSRP sessions can be done in a conventional way with 276 very little MSRP dependencies, as detailed in this document. 277 Furthermore, this usage also allows any ALG/SBC in the SIP signaling 278 path to perform media anchoring in the same way they today do for any 279 TCP connections not used for MSRP, i.e. by modifying the address:port 280 information in the c- and m-lines, and ignoring any a=path line. 282 When a UA sends an SDP offer, the MSRP URI in the a=path line of the 283 SDP offer (and eventually in the MSRP FromPath header) MAY include an 284 AoR instead of connection address information. The AoR usage works 285 fine even if the SDP answerer is a [RFC4975] conformant UA, since in 286 such cases the SDP offerer will always establish the transport 287 connection based on address information in the SDP answer. The MSRP 288 URI matching will still work since this only requires the MSRP URIs 289 in the a=path headers to be identical to the MSRP URIs in the MSRP 290 protocol FromPath and ToPath headers. 292 When a UA sends an SDP offer, the UA SHALL include an "a=msrp-acm" 293 attribute, which indicates that the UA supports the transport 294 connection addressing defined in this specifciation. 296 When a UA receives an SDP offer which contains an "a=msrp-acm" 297 attribute, the UA SHALL include the attribute in the SDP answer. 299 When a UA receives an SDP offer from an [RFC4975] conformant UA (the 300 receiving UA knows this if the SDP offer does not contain an 301 "a=setup" attribute), or the UA receives an SDP offer from a UA which 302 only supports the COMEDIA usage mechanism of this specification (the 303 receiving UA knows this if the SDP offer does not contain an "a=msrp- 304 acm" attribute), the UA needs to populate the MSRP URI in the SDP 305 answer (and eventually in the MSRP FromPath header) with an address 306 or FQDN in accordance with [RFC4975]. 308 In accordance with [RFC4975], for an MSRP endpoint that receives TCP 309 open requests to be able to use a common port for all MSRP transport 310 connections, the initiator of an MSRP transport connection SHALL 311 always after having established a new transport connection send an 312 MSRP message, allowing the other endpoint to establish the binding 313 between MSRP session and transport connection. 315 4.3. NAT keepalive 317 An MSRP endpoint behind NAT MUST keep the NAT binding alive, in 318 accordance with chapter 10 in [I.D.ietf-mmusic-ice]. The character 319 string CRLF SHOULD be sent as NAT keepalive, but if the transport 320 connection was established using ICE then STUN MAY alternatively be 321 used. 323 4.4. ICE usage 325 If the UA is using ICE for MSRP transport connection establishment, 326 it SHALL before starting to send any TCP Open requests perform the 327 normal MSRP checks for possible reuse of an existing transport 328 connection. If such is identified, the UA SHOULD preempt ICE 329 processing and send a new SIP offer which indicates a=connection: 330 existing and the SDP information for the selected connection. 332 5. Security Considerations 334 TBD 336 6. IANA Considerations 338 This document declares a new SDP attribute, "a=msrp-acm". 340 7. Acknowledgements 342 Thanks to Hadriel Kaplan and Remi Denis-Courmont for their comments 343 and input on this document. 345 8. References 347 8.1. Normative References 349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 350 Requirement Levels", BCP 14, RFC 2119, March 1997. 352 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 353 Names", BCP 32, RFC 2606, June 1999. 355 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 356 Initiation Protocol (SIP)", RFC 3323, November 2002. 358 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 359 the Session Description Protocol (SDP)", RFC 4145, 360 September 2005. 362 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 363 Transport Layer Security (TLS) Protocol in the Session 364 Description Protocol (SDP)", RFC 4572, July 2006. 366 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 367 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 369 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 370 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 371 September 2007. 373 8.2. Informative References 375 Authors' Addresses 377 Christer Holmberg 378 Ericsson 379 Hirsalantie 11 380 Jorvas 02420 381 Finland 383 Email: christer.holmberg@ericsson.com 385 Staffan Blau 386 Ericsson AB 387 P.O Box 407 388 Sweden 390 Email: staffan.blau@ericsson.com