idnits 2.17.1 draft-ietf-simple-msrp-acm-00.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? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 (January 30, 2009) is 5558 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 330, but no explicit reference was found in the text == Unused Reference: 'RFC3323' is defined on line 333, 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 (==), 2 comments (--). 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: August 3, 2009 S. Blau 5 Ericsson AB 6 January 30, 2009 8 An Alternative Connection Model for the Message Session Relay Protocol 9 (MSRP) 10 draft-ietf-simple-msrp-acm-00.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 August 3, 2009. 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 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.1.3. a=connection . . . . . . . . . . . . . . . . . . . . . 6 67 4.2. Transport connection addressing . . . . . . . . . . . . . . 6 68 4.3. NAT keepalive . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.4. ICE usage . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 MSRP [RFC4975] is designed to use MSRP relays [RFC4976] as a means 81 for NAT traversal and policy enforcement. However, in many SIP 82 networks it is often desired to deploy MSRP without the use of MSRP 83 relays, and instead use more generic NAT traversal mechanisms - such 84 as COMEDIA [RFC4145] and ICE [I.D-ietf-mmusic-ice] - while also using 85 SIP ALG controlled media relays for more application specific policy 86 control. 88 An example is the OMA defined "Instant Message using SIMPLE" [OMA-TS- 89 SIMPLE_IM-V1_0-20080312-D], where the UA of one endpoint of every 90 MSRP transport connection is a media server located in the network. 91 The media server has a global address and is handling application 92 specific policy control as well as NAT traversal, the latter through 93 use of COMEDIA which all IM MSRP clients are mandated to support. 95 Many networks where MSRP usage is emerging also contain ALGs that are 96 deployed for reasons of performance monitoring, lawful intercept, 97 address domain bridging, interconnect SLA policy enforcement, etc. A 98 typical example here is the 3GPP defined Interconnect Border Control 99 Function (IBCF) [3GPP TS23.228], which controls a media relay that 100 handles all types of SIP session media (voice, video, MSRP, etc). 101 Due to the fact that the MSRP connection model is not in a 102 conventional way using the address information in the SDP c- and 103 m-line for negotiating transport connection endpoints, and also 104 checks consistence between addresses in the MSRP protocol and in the 105 SDP a=path line, this forces the IBCF/media relay to act as an SDP 106 aware MSRP B2BUA, whereas for basically all other UDP and TCP 107 transported based media sessions it can acts as an SDP aware Relay- 108 NAPT - which is much simpler than having to act as an MSRP B2BUA. 110 To adapt MSRP to a more conventional SDP usage, which is more 111 friendly to general NAT traversal methods and to ALGs, this document 112 defines an alternative connection model for MSRP. The model differs 113 from the [RFC4975] defined model in that COMEDIA [RFC4145] is used in 114 SDP offer/answer exchanges, and that the c- and m-line address and 115 port information may be used in conventional SDP manner for 116 determining transport endpoint, meaning that the address and port 117 information in the MSRP URI in the a=path line is no longer used for 118 routing. 120 NOTE: It is possible for a UA to only use the COMEDIA mechanism of 121 the alternative connection model, but to use the MSRP routing 122 mechanism defined in [RFC4975]. 124 The alternative connection model allows conformant UAs to fall back 125 to [RFC4975] compliant behavior when interacting with [RFC4975] 126 conformant UAs. 128 2. Conventions 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in BCP 14, RFC 2119 133 [RFC2119]. 135 3. Applicability statement 137 The alternative connection model for MSRP, as defined in this 138 document, SHOULD be used when a UA does not use an MSRP relay to 139 proxy its MSRP communication. The UA SHALL use COMEDIA. If ALGs are 140 used the UA SHOULD use SDP c/m line conveyed address and port 141 information for MSRP routing, otherwise the UA MAY use the address 142 and port information conveyed in the MSRP URI (as per RFC4975). 144 UAs conformant to this document are fully interoperable with 145 [RFC4975] conformant UAs, since when interacting with such UAs they 146 will more or less fall back to [RFC4975] compliant behavior. 147 However, if a UA conformant to this document is behind NAT and 148 receives an SDP offer from an [RFC4975] conformant UA, NAT traversal 149 can only be achieved if the UA supports ICE (and the network provides 150 TURN servers) or if the network supports SBC assisted NAT traversal 151 for TCP. 153 4. The Alternative Connection Model for MSRP 155 4.1. COMEDIA usage 157 4.1.1. a=setup 159 A UA SHALL support the a=setup attribute [RFC4145], in order to 160 negotiate which endpoint is to establish the transport connection for 161 an MSRP session. 163 The support of a=setup is particularly useful when one MSRP endpoint 164 is a media server which is not behind a NAT. This since the media 165 server then make sure that transport connections for MSRP media is 166 always set up from the UA towards the server, and ensure that 167 possible NATs at user premises will not interfere with the connection 168 setup. 170 A UA SHALL always include an explicit a=setup line in SDP offers and 171 answers, since it is sometimes useful for the other endpoint, or for 172 the network, to know whether the sending endpoint supports a=setup or 173 not. 175 The a=setup "active", "actpass" and "passive" values SHALL be 176 supported, while the "holdcon" value MUST NOT be used. 178 NOTE: When the a=setup value is "actpass" or "passive", the IP 179 address:port value in the SDP MUST contain the actual address:port on 180 which the UA can receive a TCP Open request for the MSRP transport 181 connection. 183 If the a=setup value is "active", the port number value MUST either 184 be the actual port number that will be used for the TCP endpoint or 185 the port value 9. 187 The a=setup "actpass" value SHALL be used in SDP offers whenever an 188 UA can determine a valid WAN transport endpoint address:port, i.e. an 189 address:port that the other endpoint can use as destination for a TCP 190 Open request. This is in order to a) allow the other endpoint to 191 answer with "a=setup:active" if it is behind NAT, and b) to be 192 compatible with MSRP endpoints that do not support COMEDIA and thus 193 always will always act as passive endpoints. If not the actual 194 transport address can be provided then the a=setup "active" value 195 MUST be used. 197 A valid WAN transport address:port can be determined if the UA can 198 determine that it is not located behind a NAT, or if the UA relays 199 its MSRP transport connections via a TURN server, or if it through 200 STUN signaling from the local port to be used for the eventual 201 transport connection has used STUN to retrieve NAT address:port while 202 also having determined that the NAT is not address restricted. 204 If the UA is located behind a NAT, both SIP signaling and media 205 transport will pass trough it, and a UA can determine whether the 206 media transport will be NATed by inspecting the SIP Via header in the 207 200 OK response to the initial REGISTER request, comparing the IP 208 addresses in the Via sent-by and received parameters. If these are 209 not the same then there is a NAT in the path. 211 If an SDP offer includes a=setup:actpass, the SDP answer MAY include 212 a=setup:active, but SHOULD include a=setup:passive if the SDP 213 answerer knows that it is not located behind a NAT. 215 4.1.2. TLS 217 If a TLS transport connection for MSRP is negotiated, the client and 218 server TLS roles MUST negotiate the relevant parameter as specified 219 by COMEDIA-TLS [RFC4572], and in accordance with [RFC4975] the MSRP 220 URI scheme SHOULD be msrps and the m-line protocol indicator SHOULD 221 be TCP/TLS/MSRP. 223 4.1.3. a=connection 225 The a=connection attribute is defined as a means for SDP negotiation 226 of transport connection reuse. However, it seems that its use is 227 limited to mid-session SDP offer/answer exchanges while [RFC4976] 228 requires initial SDP offer/answer exchanges to result in reuse of a 229 transport connection established via another existing SIP session at 230 the same UA, if the SDP for the remote endpoint of that connection 231 indicates the same host address, port and URI scheme. 233 A UA SHALL use a=connection lines for mid-session re-negotiation of 234 transport connection for an MSRP session, but SHOULD not include any 235 a=connection line in initial SDP offer/answer exchanges (if present, 236 it SHALL be ignored by the receiving UA). Instead the connection 237 reuse principles for initial SDP offer/answer exchanges for an MSRP 238 session SHALL be in accordance with [RFC4975]. 240 4.2. Transport connection addressing 242 If the UA supports the transport connection addressing mechanism 243 defined in this chapter, the UA shall follow the procedures described 244 below. 246 The UA SHALL follow the conventional use of address information 247 received in the SDP c- and m-lines for determining the transport 248 connection endpoint address:port to connect to, instead of using the 249 address information in the MSRP URI received in the a=path line to 250 determine the remote transport connection endpoint address:port. 252 With such usage, applying COMEDIA, ICE and TLS in SDP offer/answer 253 exchanges for MSRP sessions can be done in a conventional way with 254 very little MSRP dependencies, as detailed in this document. 255 Furthermore, this usage also allows any ALG/SBC in the SIP signaling 256 path to perform media anchoring in the same way they today do for any 257 TCP connections not used for MSRP, i.e. by modifying the address:port 258 information in the c- and m-lines, and ignoring any a=path line. 260 When a UA sends an SDP offer, the MSRP URI in the a=path line of the 261 SDP offer (and eventually in the MSRP FromPath header) MAY include an 262 AoR instead of connection address information. The AoR usage works 263 fine even if the SDP answerer is a [RFC4975] conformant UA, since in 264 such cases the SDP offerer will always establish the transport 265 connection based on address information in the SDP answer. The MSRP 266 URI matching will still work since this only requires the MSRP URIs 267 in the a=path headers to be identical to the MSRP URIs in the MSRP 268 protocol FromPath and ToPath headers. 270 When a UA sends an SDP offer, the UA SHALL include an "a=msrp-acm" 271 attribute, which indicates that the UA supports the transport 272 connection addressing defined in this specifciation. 274 When a UA receives an SDP offer which contains an "a=msrp-acm" 275 attribute, the UA SHALL include the attribute in the SDP answer. 277 When a UA receives an SDP offer from an [RFC4975] conformant UA (the 278 receiving UA knows this if the SDP offer does not contain an 279 "a=setup" attribute), or the UA receives an SDP offer from a UA which 280 only supports the COMEDIA usage mechanism of this specification (the 281 receiving UA knows this if the SDP offer does not contain an "a=msrp- 282 acm" attribute), the UA needs to populate the MSRP URI in the SDP 283 answer (and eventually in the MSRP FromPath header) with an address 284 or FQDN in accordance with [RFC4975]. 286 In accordance with [RFC4975], for an MSRP endpoint that receives TCP 287 open requests to be able to use a common port for all MSRP transport 288 connections, the initiator of an MSRP transport connection SHALL 289 always after having established a new transport connection send an 290 MSRP message, allowing the other endpoint to establish the binding 291 between MSRP session and transport connection. 293 4.3. NAT keepalive 295 An MSRP endpoint behind NAT MUST keep the NAT binding alive, in 296 accordance with chapter 10 in [I.D.ietf-mmusic-ice]. The character 297 string CRLF SHOULD be sent as NAT keepalive, but if the transport 298 connection was established using ICE then STUN MAY alternatively be 299 used. 301 4.4. ICE usage 303 If the UA is using ICE for MSRP transport connection establishment, 304 it SHALL before starting to send any TCP Open requests perform the 305 normal MSRP checks for possible reuse of an existing transport 306 connection. If such is identified, the UA SHOULD preempt ICE 307 processing and send a new SIP offer which indicates a=connection: 308 existing and the SDP information for the selected connection. 310 5. Security Considerations 312 TBD 314 6. IANA Considerations 316 This document declares a new SDP attribute, "a=msrp-acm". 318 7. Acknowledgements 320 Thanks to Hadriel Kaplan and Remi Denis-Courmont for their comments 321 and input on this document. 323 8. References 325 8.1. Normative References 327 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 328 Requirement Levels", BCP 14, RFC 2119, March 1997. 330 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 331 Names", BCP 32, RFC 2606, June 1999. 333 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 334 Initiation Protocol (SIP)", RFC 3323, November 2002. 336 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 337 the Session Description Protocol (SDP)", RFC 4145, 338 September 2005. 340 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 341 Transport Layer Security (TLS) Protocol in the Session 342 Description Protocol (SDP)", RFC 4572, July 2006. 344 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 345 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 347 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 348 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 349 September 2007. 351 8.2. Informative References 352 Authors' Addresses 354 Christer Holmberg 355 Ericsson 356 Hirsalantie 11 357 Jorvas 02420 358 Finland 360 Email: christer.holmberg@ericsson.com 362 Staffan Blau 363 Ericsson AB 364 P.O Box 407 365 Sweden 367 Email: staffan.blau@ericsson.com