idnits 2.17.1 draft-macdonald-simple-msrp-opaque-path-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 368. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 379. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 386. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 392. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 instances of too long lines in the document, the longest one being 15 characters in excess of 72. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (July 7, 2008) is 5769 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE D. MacDonald 3 Internet-Draft CounterPath Solutions, Inc. 4 Intended status: Experimental H. Kaplan 5 Expires: January 8, 2009 Acme Packet 6 July 7, 2008 8 Opaque MSRP Path Uri 9 draft-macdonald-simple-msrp-opaque-path-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 8, 2009. 36 Abstract 38 The Message Session Relay Protocol(MSRP) does not allow efficient 39 topology hiding, such that MSRP users can hide the IP Address of 40 their systems. This limitation is due to the fact that MSRP Path 41 headers contain physical IP addresses. This document describes a 42 mechanism which adds a level of indirection to allow topology hiding. 43 It defines the option tag msrp-opaque. 45 Requirements Language 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119 [RFC2119]. 51 Table of Contents 53 1. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Overview of Operations . . . . . . . . . . . . . . . . . . . . 3 56 4. MSRP Opaque URI . . . . . . . . . . . . . . . . . . . . . . . 5 57 4.1. Opaque URI Parameter Format . . . . . . . . . . . . . . . 5 58 4.2. Generating an Opaque Uri Parameter . . . . . . . . . . . . 5 59 4.3. MSRP URI Parameter . . . . . . . . . . . . . . . . . . . . 5 60 5. SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . . . 5 61 6. Backwards Compatibility with RFC 4975 and 4976 . . . . . . . . 6 62 7. Example Scenario . . . . . . . . . . . . . . . . . . . . . . . 6 63 8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 65 Intellectual Property and Copyright Statements . . . . . . . . . . 10 67 1. Applicability 69 This technique may be used in any MSRP deployment where all MSRP 70 endpoints support this extension when routing on an opaque MSRP URI. 71 This document only describes an SDP based mechanism for binding a 72 physical address to an opaque MSRP URI which limits possible 73 topologies. RFC4976 [RFC4976] MSRP relays will not be able to route 74 from opaque MSRP URI's. 76 2. Introduction 78 A frequent requirement of network architectures is to hide the 79 systems of the core network from user agents. It is also often 80 desirable to hide the IP address of a user agent from other user 81 agents in the network. This is usually accomplished using a SIP 82 B2BUA or other relay element. MSRP does not allow an efficient 83 approach to this problem because the payload of the protocol contains 84 physical IP adresses, and thus the B2BUA needs to modify MSRP 85 messages in order to hide topology information. 87 This specification defines an opague MSRP URI which does not contain 88 a routable IP address. The opaque URI is a mapping to a physical 89 address which is exhanged outside the MSRP protocol. This allows 90 topology hiding without re-writing any MSRP messages that flow 91 through a SIP B2BUA, which is a very expensive operation. 93 The opaque URI is a pointer to an exernally conveyed routable URI. 94 This document describes a mechanism to convey the routable URI in the 95 SDP offer/answer exchange used to initiate the MSRP session. The 96 opaque URI is used in the MSRP message headers, while the transport 97 addressing conveyed in SDP is used for the transport layer 98 connections. 100 The basic concept is that instead of indicating the MSRP transport 101 connection information in the MSRP path SDP attribute, and using such 102 in the to-path/from-path MSRP headers, a pseudo-random string is used 103 instead: the MSRP opaque URI. An MSRP client inserts a pseudo-random 104 MSRP opaque URI value in the SDP MSRP path attribute, and uses this 105 value in MSRP messages for its path headers. Actual transport 106 connection information is instead conveyed in the standard SDP 107 connection and media lines. 109 3. Overview of Operations 111 An MSRP User Agent following this document's mechanism will generate 112 a SIP INVITE for an MSRP-based media session by populating the SDP 113 connection line and media line with transport addressing information, 114 as is done for COMEDIA., along with an MSRP opaque URI for the SDP 115 MSRP path attribute. It will also insert the new 'msrp-opaque' 116 option tag into a SIP Require header field. 118 The SIP UAS receiving the INVITE request will see the MSRP URI is an 119 opaque type, due to a new 'opaque' URI parameter defined later in 120 this document. It will then respond with an SDP answer also 121 indicating an MSRP opaque URI, with its actual transport address 122 information in the SDP connection and media lines. 124 Per RFC4975 [RFC4975]. , the UAC will initiate the TCP connection to 125 the UAS, however per this document the TCP connection would use the 126 SDP connection and media lines for addressing info instead of the 127 MSRP URI directly. If another connection model is implemented, such 128 as one following COMEDIA which allows the SIP UAS to initiate the 129 media TCP connection instead, it would still use the SDP connection 130 and media lines instead of the MSRP URI for transport addressing. 132 The MSRP messages generated by the UAC and UAS MUST continue to use 133 the MSRP path attribute opaque URI for the to/from-path MSRP headers. 134 Since the URI is not directly dereferenceable for transport 135 addressing, each UA maintains an internal binding of MSRP opaque-URI 136 to connection transport information. 138 If the TCP connection for MSRP were to go directly from the UAC to 139 the UAS, then clearly one could simply learn the UA addressing on the 140 wire, or by looking at SDP information, and anonymity would not be 141 achieved. It is expected that in typical deployment the media 142 transport information is obfuscated through some other means, such as 143 SBC's or ALG's performing media relay functions, or whatever; but 144 that is beyond the scope of this document. The goal of this document 145 is to provide anonymity for MSRP, not SIP nor SDP. 147 The approach defined in this document does not fit with the MSRP 148 Relay model of RFC 4976, where an MSRP client can use a special 149 intermediary called an "MSRP Relay". Such devices have seen very 150 limited deployment, if any. Instead, most intermediaries are MSRP 151 Application Servers, acting as full MSRP Back-to-Back User Agents, or 152 they are typical SIP intermediate types of devices, such as SBCs and 153 ALGs. One of the goals of this specification is to be able to make 154 MSRP work across such intermediaries. 156 [Note: the MSRP opaque URI model *could* be made to work with MSRP 157 Relays, if the Relays were to know about such URIs in advance - it is 158 TBD whether it is worth specifying how that could/should work] 160 4. MSRP Opaque URI 162 4.1. Opaque URI Parameter Format 164 The opaque URI is an MSRP URI which has an 'opaque' URI parameter as 165 defined later. The opaque URI param is globally unique. If an 166 client wants to use the opaque URI for anonyminity it will use the 167 .invalid domain. For example: path:msrp://msrp.invalid.com:7394/ 168 2s93u93udj;tcp;opaque=f7jey483rydfhkyerky3. The port has no meaning 169 when the invalid domain is used. 171 This allows backwards compatibility with MSRP implementations that do 172 not support this extension if a valid URI is used. 174 4.2. Generating an Opaque Uri Parameter 176 TODO: determine generation scheme and encoding 178 4.3. MSRP URI Parameter 180 This document defines a new MSRP URI parameter: "opaque". The opaque 181 URI parameter is a token which is globally unique and can be used to 182 map back to a TCP(or other protocol) connection. The ABNF for this 183 parameter, following RFC4975 [RFC4975], is as follows: 185 URI-parameter = opaque-param / (token ["=" token]) 186 opaque-param = "opaque" EQUAL token 188 5. SIP Option Tag 190 This specification registers a new SIP option tag, as per the 191 guidelines in Section 27.1 of RFC3261 [RFC3261]. 193 Name: msrp-opaque 195 Description: This option-tag is used to identify UAs which support 196 the mechanism defined in this document. 198 SIP User Agents MUST include a Requires header field with the "msrp- 199 opaque" option-tag when using an invalid URI with an opaque parameter 200 in an SDP offer or answer in a SIP message. 202 SIP User Agents SHOULD include a Supported header field with an the 203 "msrp-opaque" option-tag if they support this specification but still 204 wish to generate a valid URI in the SDP. This allows the UAS to 205 reject the request with a Require header field containing "msrp- 206 opaque" to indicate the UAS requires the UAC to use an opaque URI; 207 and this allows for backwards compatibility as described in the next 208 section. 210 6. Backwards Compatibility with RFC 4975 and 4976 212 When a UAC initiates an MSRP session, it may need to interoperate 213 with legacy devices based on RFC 4975 and 4976. This can be 214 accomplished with the opaque URI mechanism in the following way, as 215 long as the UAC does not itself require anonymization of its URI: the 216 UAC generates a legacy RFC 4975 MSRP URI, but adds an 'opaque' 217 parameter to the end of it, and sets the SDP connection and media 218 lines to be the real transport addresses as well, and adds a 219 Supported option tag of "msrp-opaque". 221 If the answering UAS only supports RFC 4975 and/or 4976, it will 222 ignore the opaque parameter and Supported option tag, and respond and 223 act as per RFC 4975. If the UAS supports the opaque mechanism, and 224 wishes to anonymize its MSRP URI, it responds with an invalid URI 225 with an opaque parameter and a SIP Require header field with the 226 "msrp-opaque" option tag. 228 7. Example Scenario 230 In the following example, Alice invites Bob to an MSRP session. 231 Alice does not wish her IP address to be known, as it conveys 232 information about her location and might make her system vulnerable 233 to attacks. Similarily, the Atlanta network has a policy of not 234 exposing such details about their network or their users. In this 235 case Alice and Bob are both at atlanta.example.com 237 Alice Atlanta Network Bob 238 | | | 239 |------INVITE------->| 1 | 240 | |------INVITE------>| 2 241 | |<------200---------| 3 242 |<------200----------| 4 | 243 |-------ACK--------->| | 244 | |-------ACK-------->| 245 | | | 247 Message 1 is an INVITE where msrp-opaque is required and an opaque 248 MSRP URI is used in the SDP. 250 INVITE sip:bob@atlanta.example.com SIP/2.0 251 To: 252 From: ;tag=786 253 Call-ID: 3413an89KU 254 Requires: msrp-opaque 255 Content-Type: application/sdp 256 - 257 c=IN IP4 192.168.0.100 258 m=message 12454 TCP/MSRP * 259 a=path:msrp://msrp.invalid.com:7394/jshA7weztas;tcp;opaque=f7jey483rydfhkyerky3 261 The connection c-line of the SDP identifies Alice's actual transport 262 address for the MSRP connection, and the media m-line port portion 263 identifies the TCP port; as opposed to the msrp path attribute as 264 defined in RFC4975 [RFC4975]. They may be changed by intermediate 265 nodes to point to an address:port on a TCP relay service in the 266 Atlanta network. 268 c=IN IP4 border.altanta.example.com 269 m=message 22454 TCP/MSRP * 270 a=path:msrp://msrp.invalid.com:7394/jshA7weztas;tcp;opaque=f7jey483rydfhkyerky3 272 The relevant portion on the SDP from Message 3. For simplicity, 273 Bob's UA has been given a publicly reachable IP address. 275 c=IN IP4 bob.altanta.example.com 276 m=message 34313 TCP/MSRP * 277 a=path:msrp://msrp.invalid.com:7394/kjhd37s2s20w2a;tcp;opaque=a6ghr7yv6egw33r 279 Which is re-written to point to the border element. 281 c=IN IP4 border.altanta.example.com 282 m=message 27784 TCP/MSRP * 283 a=path:msrp://msrp.invalid.com:7394/kjhd37s2s20w2a;tcp;opaque=a6ghr7yv6egw33r 285 After this exchange is complete Alice will form a connection to the 286 border.atlanta.example.com which will in turn connect to Bob's UA. 287 border.atlanta.example.com acts as a simple TCP relay between Bob and 288 Alice until the TCP connection is torn down by either party. 290 While some of this functionality can be achieved with the MSRP relay 291 specification, or by using TURN-TCP, this approach has it's own 292 advantages and disadvantages. 294 Advantages: 296 The opaque-uri can provide topology hiding. This can also be 297 provided by TURN-TCP, but will end up w/ two TURN allocations 298 being used. 300 At the media level, the opaque-uri approach only requires a TCP 301 relay which has no knowledge of MSRP. 303 It is a small change for endpoints which already support MSRP. 305 Disadvantages: 307 Until the TCP relay has connected to the second peer(Bob), any 308 MSRP requests from Alice must be rate-limited or cached. In 309 practice, rate limiting seems to work well; if the connection to 310 Bob fails, the connection to Alice would be torn down. This does 311 not provide the same level of error reporting as MSRP-Relay. 313 Mapping rules must be conveyed from the signal-plane(SIP/SDP) to 314 the Media Plane(TCP relay) 316 8. Normative References 318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 319 Requirement Levels", BCP 14, RFC 2119, March 1997. 321 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 322 A., Peterson, J., Sparks, R., Handley, M., and E. 323 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 324 June 2002. 326 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 327 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 329 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 330 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 331 September 2007. 333 Authors' Addresses 335 Derek C. MacDonald 336 CounterPath Solutions, Inc. 337 Suite 300, One Bentall Centre, 505 Burrard St 338 Vancouver, BC V7X1M3 339 Canada 341 Phone: +1-604-320-3344 342 Email: derek@counterpath.com 343 Hadriel Kaplan 344 Acme Packet 345 71 Third Ave. 346 Burlington, MA 01803 347 USA 349 Phone: 350 Fax: 351 Email: hkaplan@acmepacket.com 352 URI: 354 Full Copyright Statement 356 Copyright (C) The IETF Trust (2008). 358 This document is subject to the rights, licenses and restrictions 359 contained in BCP 78, and except as set forth therein, the authors 360 retain all their rights. 362 This document and the information contained herein are provided on an 363 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 364 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 365 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 366 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 367 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 368 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 370 Intellectual Property 372 The IETF takes no position regarding the validity or scope of any 373 Intellectual Property Rights or other rights that might be claimed to 374 pertain to the implementation or use of the technology described in 375 this document or the extent to which any license under such rights 376 might or might not be available; nor does it represent that it has 377 made any independent effort to identify any such rights. Information 378 on the procedures with respect to rights in RFC documents can be 379 found in BCP 78 and BCP 79. 381 Copies of IPR disclosures made to the IETF Secretariat and any 382 assurances of licenses to be made available, or the result of an 383 attempt made to obtain a general license or permission for the use of 384 such proprietary rights by implementers or users of this 385 specification can be obtained from the IETF on-line IPR repository at 386 http://www.ietf.org/ipr. 388 The IETF invites any interested party to bring to its attention any 389 copyrights, patents or patent applications, or other proprietary 390 rights that may cover technology that may be required to implement 391 this standard. Please address the information to the IETF at 392 ietf-ipr@ietf.org.