idnits 2.17.1 draft-rosenberg-sip-route-construct-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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 696. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 673. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 680. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 686. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 17, 2006) is 6373 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) == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-04 == Outdated reference: A later version (-02) exists of draft-rosenberg-sip-ua-loose-route-00 == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-09 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP J. Rosenberg 3 Internet-Draft Cisco Systems 4 Expires: April 20, 2007 October 17, 2006 6 Construction of the Route Header Field in the Session Initiation 7 Protocol (SIP) 8 draft-rosenberg-sip-route-construct-02 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of 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 April 20, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 The Route header field in the Session Initiation Protocol (SIP) is 42 used to cause a request to visit a set of hops on its way towards the 43 final destination. Several specifications have defined rules for how 44 a user agent obtains and then uses a set of Route header fields in 45 the transmission of a request. These include the SIP specification 46 itself, the Service-Route header field specification, the SIP server 47 option in the Dynamic Host Configuration Protocol (DHCP), and others. 48 Unfortunately, these specifications are not consistent and the 49 resulting behavior at clients and servers is not clear or complete. 50 This document resolves this problem by defining a consistent set of 51 logic, and in the process, serves as an update to the Service-Route 52 specification. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Existing Sources . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Default Outbound Proxies . . . . . . . . . . . . . . . . . 3 59 2.2. Service Route . . . . . . . . . . . . . . . . . . . . . . 4 60 2.3. Record-Routes . . . . . . . . . . . . . . . . . . . . . . 4 61 2.4. Loose Routes . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Problems with Current Specifications . . . . . . . . . . . . . 5 63 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 5. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 65 6. Detailed Processing Rules . . . . . . . . . . . . . . . . . . 7 66 6.1. Registrar Behavior . . . . . . . . . . . . . . . . . . . . 8 67 6.2. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 10 68 6.3. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 10 69 6.3.1. REGISTER Processing . . . . . . . . . . . . . . . . . 10 70 6.3.2. Request Origination . . . . . . . . . . . . . . . . . 11 71 7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 74 9.1. SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . 13 75 9.2. Header Field Parameter . . . . . . . . . . . . . . . . . . 13 76 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 78 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14 80 12.2. Informative References . . . . . . . . . . . . . . . . . . 14 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 Intellectual Property and Copyright Statements . . . . . . . . . . 17 84 1. Introduction 86 The Route header field in the Session Initiation Protocol (SIP) 87 protocol is used to cause a request to visit a set of hops on its way 88 towards the final destination. RFC 3261 [2] discusses how a client 89 constructs the Route header field for requests. However, this logic 90 is restricted to mid-dialog requests, where the route set was learned 91 as a result of record-routing. 93 However, additional sources of routes can exist for a UA. These 94 include default outbound proxies, a service route learned from the 95 Service-Route header field [3], and a redirection utilizing loose 96 routing [7]. In total, there are four sources of potential route 97 headers. The way in which these various sources are reconciled is 98 unclear. Furthermore, the various specifications are unclear about 99 which requests these Route headers are applicable to. Do they apply 100 to REGISTER? Do they apply to mid-dialog requests? Finally, RFC 101 3608 is underspecified, which can result in interoperability 102 problems. 104 Section 2 reviews the existing sources of route sources. Section 3 105 discusses problems with the existing specifications. Section 5 106 overviews the proposed changes in behavior. Section 6 provides a 107 detailed description of element behavior, and Section 7 defines the 108 grammar for the new parameters specified here. 110 2. Existing Sources 112 This section examines the current set of route header field sources. 114 2.1. Default Outbound Proxies 116 RFC 3261 discusses default outbound proxies. In Section 8.1.1.1, it 117 makes reference to its interaction with Route header fields: 119 In some special circumstances, the presence of a pre-existing 120 route set can affect the Request-URI of the message. A pre- 121 existing route set is an ordered set of URIs that identify a chain 122 of servers, to which a UAC will send outgoing requests that are 123 outside of a dialog. Commonly, they are configured on the UA by a 124 user or service provider manually, or through some other non-SIP 125 mechanism. When a provider wishes to configure a UA with an 126 outbound proxy, it is RECOMMENDED that this be done by providing 127 it with a pre-existing route set with a single URI, that of the 128 outbound proxy. 130 When a pre-existing route set is present, the procedures for 131 populating the Request-URI and Route header field detailed in 132 Section 12.2.1.1 MUST be followed (even though there is no 133 dialog), using the desired Request-URI as the remote target URI. 135 The default outbound proxy can be learned either through DHCP [8], 136 through configuration (such as the SIP configuration framework [9]), 137 or through other means. In the IP Multimedia Subsystem (IMS), the 138 default outbound proxy is the P-CSCF and is learned through GPRS 139 specific techniques. 141 RFC 3261 does not explicitly say the set of messages to which this 142 route set applies. However, the text above implies that it is for 143 all requests outside of a dialog. 145 2.2. Service Route 147 RFC 3608 specifies the Service-Route header field. This header field 148 is provided to the UA in a 2xx response to a REGISTER request. The 149 client uses this to populate its Route header fields for outgoing 150 requests. However, RFC 3608 explicitly says that the decision a UA 151 makes about how it combines the service route with other outbound 152 routes is a matter of local policy. Furthermore, RFC 3608 does not 153 clearly define to which requests the service route applies, and in 154 particular, whether or not it applies to a REGISTER request or a mid- 155 dialog request. 157 Furthermore, RFC 3608 specifies that a service-route is associated 158 with an Address-of-Record (AOR), and is shared by all contacts 159 associated with the same AOR. It also specifies that the Service- 160 Route URI can only be ones known to the registrar apriori, as opposed 161 to learned through the registration itself. 163 2.3. Record-Routes 165 RFC 3261 provides a detailed description of the record-routing 166 mechanism, and how the user agents in a dialog construct route sets 167 from the Record-Route header field values. RFC 3261 is also clear 168 that the resulting route set applies to mid-dialog requests. It 169 implies (though does not explicitly say) that the resulting route set 170 overrides any default outbound proxies (which represent a pre-loaded 171 route set). 173 2.4. Loose Routes 175 Loose routing, introduced in [7], defines mechanisms for using Route 176 header fields to address and invoke services in a user agent. It 177 also specifies a redirection mechanism whereby a server can redirect 178 a client, and ask it to either modify the topmost Route header field 179 of its request, or add a new Route header field to the topmost 180 request. The specification indicates that it is applicable to both 181 mid-dialog and out-of-dialog requests. Since the client can be a 182 user agent, this forms another potential source of a Route header 183 field for user agents. 185 3. Problems with Current Specifications 187 Numerous problems have arisen as a consequence of the combination of 188 these specifications. These problems fit into two categories. The 189 first are interoperability problems, and the second are missing 190 capabilities. 192 An interoperability problem that has arisen is keeping an outbound 193 proxy on the path for outbound requests. Consider a proxy in a hotel 194 which a client discovers via DHCP and uses as its outbound proxy. 195 This proxy wishes to be used for incoming and outgoing requests, both 196 in and out of a dialog. If the home proxy provides a service route, 197 the hotel proxy will not be able to determine what it needs to do in 198 order to stay on the path. If the client implementation is such that 199 it appends the service route to its default outbound proxy, then the 200 hotel proxy need not do anything to stay on the path. If, however, 201 the client abandons its default proxy in favor of the service route, 202 the hotel proxy would fall off the path of subsequent requests unless 203 it inserted a Service-Route into the response of a REGISTER request. 204 Interestingly, the latter is illegal behavior according to RFC 3608, 205 but is the only mechanism available for ensuring that a proxy stay on 206 the request path. Since RFC 3608 does not provide any normative 207 behavior for combining service routes and outbound proxies, the hotel 208 proxy cannot know what to do, thus causing the interoperability 209 problem. 211 This points to the first major functional gap with RFC 3608. There 212 is no standards-based way for keeping an outbound proxy on the path 213 for outbound requests, when it is not the default outbound proxy. 214 Consider a proxy in a hotel, PH-1 which a client discovers via DHCP 215 and uses as its outbound proxy. When the client sends a REGISTER to 216 this proxy, it forwards it to a second proxy in the hotel, PH-2, 217 which then forwards it to the home proxy of the user, PA. PH-2 needs 218 to be on the outbound path for all requests leaving the hotel. PA 219 includes itself in a Service-Route header field in the response. The 220 client receives this Service-Route. For an initial INVITE request, 221 the client constructs a route set which includes its outbound proxy 222 PH-1 followed by the URI from the Service-Route, PA. This request 223 will traverse PH-1, which now follows the next Route header, sending 224 it to PA. This is not the desired behavior. The problem is that the 225 Service-Route URI has provided a route that overrides the default 226 outbound route behavior at PH-1. 228 Similarly, there is no way in RFC 3608 to change the outbound proxy, 229 outside of an update in the client configuration. Such changes are 230 extremely useful for many operational reasons. One example is 231 movement of subscribers between geographically distributed sites in 232 cases where a site must be gracefully taken out of service, and the 233 subscribers using it need to be moved gracefully, over a period of an 234 hour or two, from one site to the other. Since, at best, the impact 235 of Service-Route on the outbound proxy is ambiguous, there is 236 generally no way to affect it excepting configuration change. Using 237 configuration updates as the only way to alter the outbound proxy is 238 problematic. In practice, systems providing automated updates to 239 client configuration (when they exist, as they often do not) are 240 decoupled from the operational systems that manage subscriber 241 capacity and software upgrades of sites, making the change hard to 242 affect through configuration. Furthermore, configuration updates are 243 typically passed to clients once they are made. Here, however, the 244 objective is to gracefully move subscribers. Using the randomized 245 nature of REGISTER timings helps provide that; such a function is 246 difficult to accomplish through configuration updates. Finally, many 247 deployments use mechanisms other than [9] for updating client 248 configurations. As a consequence, there is no common way across 249 deployments to provide this very basic operational feature. 251 Another problem that has come up with RFC 3608 is that it will not 252 work well with mid-dialog failover techniques identified for SIP 253 Outbound [10]. These techniques require that the outbound proxy 254 construct a URI for the Service-Route that is used by the UA for new 255 requests outside of a dialog. 257 Finally, RFC 3608 is defined such that the service route is identical 258 for all contacts registered to a specific AOR. This makes it 259 applicable only for selecting a set of configured, well-known servers 260 to use, and only ones within the domain of the owner of that AOR. 261 This is a fairly narrow scope of applicability, and introduces a 262 configuration burden on the registrar. 264 Architecturally, there is an inconsistency between record-routing and 265 service route. With record-route, each proxy on the path of the 266 request inserts a Record-Route header field, and this dictates the 267 path of subsequent messages within a dialog both to and from the UA. 268 With REGISTER, each proxy on the path of the request inserts a Path 269 [4] header field to receive requests directed towards the client. 270 However, the Service-Route is not the inverse of the Path, and is 271 instead created through proprietary means by the registrar. 273 4. Terminology 275 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 276 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 277 document are to be interpreted as described in RFC 2119 [1]. 279 5. Overview of Operation 281 This specification updates the behaviors in RFC 3608. In particular, 282 a registrar, upon receipt of a REGISTER, uses the Path header field 283 values to construct the Service-Route in the response. In addition, 284 the registrar retains an instance of the Path (and resulting Service 285 Route) for each registered contact. The Path and Service-Route 286 remain valid for the duration of the registration, and are updated 287 for each registration refresh. 289 In order to retain backwards compatibility with systems based on RFC 290 3608, proxies compliant to this specification include a flag, "p2sr", 291 in their Path header field values. When the registrar receives the 292 REGISTER request, it examines the sequence of Path header field URI. 293 If it sees that one or more contiguous proxies at the end of the Path 294 sequence do not support this mechanism, the registrar omits those URI 295 from the Service-Route, and omits the Require header field parameter 296 indicating support for this specification in the response. This 297 causes the UA to revert to existing behavior, augmenting the route 298 set with the outbound proxy [[OPEN ISSUE: well, thats true for IMS at 299 least. UA behavior isn't defined at all in this area in RFC 3608. 300 Alternative is to have two option tags - one that says to augment, 301 and one that says don't.]] If, however, all of the Path URI include 302 the "p2sr" flag, an option tag is placed into the Require header 303 field is placed in the response, indicating that the Service-Route 304 overrides the outbound proxy. 306 The rules for constructing the Route for a request at the UA follow 307 in a straightforward manner from this. Mid-dialog requests always 308 use the set of URI learned from the Record-Route. A request outside 309 of the scope of a dialog, including a REGISTER refresh, uses the 310 Service-Route, and based on the Require flag, may or may not override 311 the outbound proxy. Finally, in all cases, if a request generates a 312 redirect response that contains a loose route, the Route set is 313 further modified or augmented based on the redirection. 315 6. Detailed Processing Rules 316 6.1. Registrar Behavior 318 This specification updates the procedures from RFC 3608. 320 The procedures in this specification MUST NOT be followed unless the 321 REGISTER request contains a Supported header field with the "sr" 322 option tag. 324 Assuming the REGISTER request contains this option tag, the registrar 325 examines the set of Path header field values, starting from the top 326 (the proxy closes to, but not including the registrar itself) towards 327 the bottom (the proxy farthest away from the registrar). If the 328 registrar is planning on adding itself to the Service-Route, it adds 329 itself to the top of the list. Its own URI MUST include the "p2sr" 330 Path header field parameter. 332 If the resulting list is such that there are 0 or more contiguous 333 values starting at the top which contain the "p2sr" Path header field 334 parameter, followed by 0 or more contiguous values which do not 335 contain this parameter, the registrar SHOULD follow the remaining 336 procedures of this specification in the construction of the Service- 337 Route header field in the response. If not, the procedures defined 338 here MUST NOT be used. In addition, if none of the Path header field 339 values contain the "p2sr" Path header field parameters, the 340 procedures defined here MUST NOT be used. 342 Consider the example network of Figure 1. The UAC is separated from 343 the registrar by three proxies, P1, P2 and P3. The UAC supports the 344 mechanism in this specification and indicates this through the "sr" 345 option tag in the Supported header field of its REGISTER request. 347 +------+ +------+ +------+ +------+ +------+ 348 | | | | | | | | | | 349 | UAC |---->| P1 |----->| P2 |----->| P3 |----->| Reg | 350 | | | | | | | | | | 351 +------+ +------+ +------+ +------+ +------+ 353 Figure 1 355 When the UAC registers, each of the proxies inserts itself onto the 356 Path header field of the REGISTER. Each of the proxies either 357 supports this extension (and thus inserts a "ps2r" parameter into its 358 Path header field value) or it does not (in which case no parameter 359 is inserted). The following table shows, for various Path sequences, 360 whether or not the modified Service-Route procedures of this 361 specification would be used. 363 Path Header Field | Use New SR | Notes 364 | Procedures? | 365 -------------------------------------------------------------------- 366 P3;p2sr, | | 367 P2;p2sr, | Y | All proxies support it 368 P1;p2sr | | 369 -------------------------------------------------------------------- 370 P3;p2sr, | | Proxies closest to registrar 371 P2;p2sr, | Y | support, followed by ones 372 P1 | | that don't 373 -------------------------------------------------------------------- 374 P3;p2sr, | | Proxies closest to registrar 375 P2 | Y | support, followed by ones 376 P1 | | that don't 377 -------------------------------------------------------------------- 378 P3, | | 379 P2, | N | No proxies support it 380 P1 | | 381 -------------------------------------------------------------------- 382 reg;p2sr | | 383 P3, | |Registrar planning on inserting 384 P2, | Y |itself onto the Service-Route 385 P1 | | 386 -------------------------------------------------------------------- 387 P3, | | Set of proxies that support 388 P2;p2sr, | N | it must be contiguous and 389 P1 | | closest to registrar 390 -------------------------------------------------------------------- 391 P3;p2sr, | | Set of proxies that support 392 P2, | N | it must be contiguous and 393 P1;p2sr | | closest to registrar 394 -------------------------------------------------------------------- 396 Figure 2 398 This constraint basically says that the Path has to be built 399 either by a proxy chain which all support this spec, or by a chain 400 whereby a bunch didn't support it, followed by a bunch that did. 401 This works well in IMS deployments where the visited network 402 doesn't support the mechanism, but the home network does. 404 If the mechanisms in this specification are to be used, the registrar 405 MUST construct the Service-Route in the registration response by 406 taking each URI from the list which contained the "p2sr" header field 407 parameter, and inverting the order. The registrar MUST add an option 408 tag to the Require header field in the response (adding the header 409 field if necessary) with the value "sr". The URI in the Service- 410 Route header field values SHOULD NOT contain the "p2sr" parameter; 411 that parameter is a Path header field value and is not needed in the 412 Service-Route. 414 The resulting Service-Route MUST be recomputed for each registration 415 refresh, and for each new registration. The server MAY store the 416 values associated with it, though this is not necessary for proper 417 operation of this specification. 419 In addition, the registrar MUST only return in a 200 OK response to 420 the REGISTER request, the Contact header field associated with the 421 registration which was just performed. [[OPEN ISSUE: This is really 422 orthogonal, and it is probably controversial. Basically it proposes 423 to use this new service route mechanism as a vehicle for eliminating 424 query registers and third party registrations.]]. A UA compliant to 425 this specification will never generate a registration with anything 426 except for a single Contact. 428 If the mechanisms in this specification are not used, the registrar 429 MUST follow the procedures of RFC 3608 and construct the Service- 430 Route as it would otherwise. It MUST omit the "sr" option tag from a 431 Require header field in the response. 433 6.2. Proxy Behavior 435 This specification updates the proxy processing rules in RFC 3608. 437 A proxy compliant to this specification which inserts a Path header 438 field value into a REGISTER request MUST include a "p2sr" Path header 439 field parameter with its value. If the response to the REGISTER 440 request includes the Require header field that includes the "sr" 441 option tag, it means that the UA will be using that URI (which will 442 be echoed in the Service-Route) as a Route header field value for 443 requests outside of a dialog. In this case, the proxy MAY remove its 444 value from the Service-Route in the response, or MAY modify it. 446 When the UA initiates a request outside of a dialog, that request 447 will contain a route set which includes the URIs learned from the 448 Service-Route. Consequently, a proxy MUST be prepared to receive 449 such a request, in which case the topmost Route header will be the 450 URI the proxy passed to the UA in the 200 OK response to REGISTER. 452 6.3. UAC Behavior 454 6.3.1. REGISTER Processing 456 A UA compliant to this specification MUST include the "sr" option tag 457 in the Supported header field of its REGISTER request. Such a UA 458 MUST include only a single Contact in each REGISTER request, which 459 points to the UA performing the registration. It MUST NOT generate a 460 "query REGISTER" which contains no contacts, MUST NOT include 461 multiple Contact header field values in its registration, and MUST 462 NOT register a Contact which does not directly point to the UA 463 itself. 465 When the REGISTER response arrives, and it is a 2xx response, the UA 466 looks for the presence of a Supported header field in the response 467 with the "sr" option tag. If present, the UA is operating in 468 "override" mode, as described below. If not present, the UA is 469 operating in "augment" mode, as described below. In either case, the 470 UA MUST cache the contents of the Service-Route header field for the 471 duration of its registration. 473 A single UA may still be performing multiple registrations, for 474 purposes of high availability, as a consequence of the procedures 475 defined in SIP outbound [6]. In this case, the UA will end up with 476 multiple sets of Service-Route, each of which is bound to the 477 particular flow that was registered (and its associated Contact). 479 6.3.2. Request Origination 481 It is RECOMMENDED that a UA compliant to this specification also be 482 compliant to UA loose routing [7]. This allows proxies to utilize a 483 redirection to further augment the way in which the route set for a 484 request is constructed. 486 The primary question addressed by this specification is how the UA 487 constructs the route set for a request. 489 Determination of the route set for a request depends on whether the 490 request is generated as a consequence of a redirection. If the UA 491 indicated support for loose routing in its request (as described in 492 [7], the Route set for the recursed request is generated from the 493 request which generated the recursion, as described there. 495 This specification assumes that a UA may have one or more configured 496 outbound proxies, each in the form of a SIP URI. Each of these will 497 either be a loose route (in which case the request would contain that 498 URI in the Route header field) or not (in which case the UA will just 499 send the request to that target without including its URI in the 500 topmost Route request). 502 For a request sent by a UAC that is not the result loose route 503 recursion, the following logic MUST be used to compute the route set: 505 o If the request is a mid-dialog request, the route set is computed 506 per the procedures in Section 12.2.1.1 of RFC 3261. The route set 507 will not contain any routes learned from configuration, DHCP, 508 Service-Route or any other mechanism. 510 o If the request is not a mid-dialog request, the client checks to 511 see if it has learned a service route as a result of registration. 512 The UAC may have learned numerous service routes, one for each 513 unique AOR/Contact that it registered. In the case of 514 registrations using the mechanisms of [6], the Contact includes 515 the flow ID and instance ID, so that the client may have a 516 distinct service route for each unique AOR/Flow ID/Instance ID 517 combination. As such, when sending a request, the client selects 518 the service route corresponding to the contact which is sending 519 the request. [[OPEN ISSUE: Need to say more about this 520 selection.]]. If the UA is operating in "override" mode for this 521 route set, the URIs from this service route become the route set. 522 If the UA is operating in the "augment" mode for this route set, 523 the UA takes the outbound proxy URI it used for the REGISTER 524 request which created the route set, and appends that URI to the 525 top of the service route. 527 o If the request is not a mid-dialog request, and there are are no 528 service routes associated with the contact generating the request, 529 the UAC uses the route set learned through configuration. [[OPEN 530 ISSUE: Do we need to specify how to reconcile route sources 531 learned across disparate configuration sources? For example DHCP 532 and a config file? These can come from different providers.]] 534 If the topmost URI in the resulting route set is not a loose route 535 (which can happen when there is a configured outbound proxy that is 536 not a loose route), the UA MUST remove that URI from the Route set, 537 but still use it for purposes of sending the request. 539 7. Grammar 541 This specification defines an option tag and a Path header field 542 parameter. Their syntax is as follows: 544 option-tag \= "sr" 545 rr-param \= "p2sr" 547 8. Security Considerations 549 The route set used by a user agent for generating initial requests 550 into the network is very sensitive information. If this information 551 is manipulated by an attacker, it can cause calls to be directed 552 towards intermediaries, which can then observe call patterns, 553 intercept communications, and so on. Consequently, a UA using this 554 specification SHOULD use sips when performing a registration. This 555 makes sure that only entities along the request path can modify the 556 route set used by the UA. 558 Even with sips, it is possible that a malicious home proxy could 559 modify the route set used by the UA, eliminating the outbound proxy 560 that would otherwise be used by it. This kind of attack is only 561 meaningful in environments where the outbound proxy is in a different 562 domain than the home proxy. However, presumably the outbound proxy 563 is present to authorize access to services, and removing it will only 564 result in denial of service to the user, which would appear to 565 provide no benefit. 567 9. IANA Considerations 569 This specification registers a new option tag and a new Path header 570 field parameter. 572 9.1. SIP Option Tag 574 This specification registers a new SIP option tag, as per the 575 guidelines in Section 27.1 of RFC 3261. 577 Name: sr 579 Description: This option tag is used to identify the usage of Path 580 reflected Service-Route, as defined by RFC XXXX [[NOTE TO IANA: 581 Please replace XXXX with the RFC number of this specification]] 583 9.2. Header Field Parameter 585 This specification defines the "p2sr" header field parameter, as per 586 the registry created by [5]. The required information is as follows: 588 Header field in which the parameter can appear: Path 590 Name of the Parameter: p2sr 592 RFC Reference: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 593 RFC number of this specification.]] 595 10. Examples 597 TODO. 599 11. Acknowledgements 601 The author would like to thank Paul Kyzivat and Anders Kristensen for 602 their comments. 604 12. References 606 12.1. Normative References 608 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 609 Levels", BCP 14, RFC 2119, March 1997. 611 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 612 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 613 Session Initiation Protocol", RFC 3261, June 2002. 615 [3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) 616 Extension Header Field for Service Route Discovery During 617 Registration", RFC 3608, October 2003. 619 [4] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) 620 Extension Header Field for Registering Non-Adjacent Contacts", 621 RFC 3327, December 2002. 623 [5] Camarillo, G., "The Internet Assigned Number Authority (IANA) 624 Header Field Parameter Registry for the Session Initiation 625 Protocol (SIP)", BCP 98, RFC 3968, December 2004. 627 [6] Jennings, C. and R. Mahy, "Managing Client Initiated Connections 628 in the Session Initiation Protocol (SIP)", 629 draft-ietf-sip-outbound-04 (work in progress), June 2006. 631 [7] Rosenberg, J., "User Agent Loose Routing in the Session 632 Initiation Protocol (SIP)", 633 draft-rosenberg-sip-ua-loose-route-00 (work in progress), 634 October 2006. 636 12.2. Informative References 638 [8] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP- 639 for-IPv4) Option for Session Initiation Protocol (SIP) 640 Servers", RFC 3361, August 2002. 642 [9] Petrie, D., "A Framework for Session Initiation Protocol User 643 Agent Profile Delivery", draft-ietf-sipping-config-framework-09 644 (work in progress), October 2006. 646 [10] Rosenberg, J., "Discovering Outbound Proxies and Providing High 647 Availability with Client Initiated Connections in the Session 648 Initiation Protocol (SIP)", 649 draft-rosenberg-sip-outbound-discovery-mid-dialog-00 (work in 650 progress), October 2006. 652 Author's Address 654 Jonathan Rosenberg 655 Cisco Systems 656 600 Lanidex Plaza 657 Parsippany, NJ 07054 658 US 660 Phone: +1 973 952-5000 661 Email: jdrosen@cisco.com 662 URI: http://www.jdrosen.net 664 Intellectual Property Statement 666 The IETF takes no position regarding the validity or scope of any 667 Intellectual Property Rights or other rights that might be claimed to 668 pertain to the implementation or use of the technology described in 669 this document or the extent to which any license under such rights 670 might or might not be available; nor does it represent that it has 671 made any independent effort to identify any such rights. Information 672 on the procedures with respect to rights in RFC documents can be 673 found in BCP 78 and BCP 79. 675 Copies of IPR disclosures made to the IETF Secretariat and any 676 assurances of licenses to be made available, or the result of an 677 attempt made to obtain a general license or permission for the use of 678 such proprietary rights by implementers or users of this 679 specification can be obtained from the IETF on-line IPR repository at 680 http://www.ietf.org/ipr. 682 The IETF invites any interested party to bring to its attention any 683 copyrights, patents or patent applications, or other proprietary 684 rights that may cover technology that may be required to implement 685 this standard. Please address the information to the IETF at 686 ietf-ipr@ietf.org. 688 Disclaimer of Validity 690 This document and the information contained herein are provided on an 691 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 692 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 693 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 694 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 695 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 696 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 698 Copyright Statement 700 Copyright (C) The Internet Society (2006). This document is subject 701 to the rights, licenses and restrictions contained in BCP 78, and 702 except as set forth therein, the authors retain all their rights. 704 Acknowledgment 706 Funding for the RFC Editor function is currently provided by the 707 Internet Society.