idnits 2.17.1 draft-ietf-sip-scvrtdisco-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 are 28 instances of too long lines in the document, the longest one being 7 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 == Line 249 has weird spacing: '... where prox...' -- 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 (May 13, 2003) is 7654 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '1' is defined on line 656, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 662, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2223 (ref. '3') (Obsoleted by RFC 7322) ** Obsolete normative reference: RFC 3427 (ref. '6') (Obsoleted by RFC 5727) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP -- Session Initiation Protocol D. Willis 3 Working Group dynamicsoft Inc. 4 Internet-Draft B. Hoeneisen 5 Expires: November 11, 2003 Switch 6 May 13, 2003 8 Session Initiation Protocol Extension Header Field for Service Route 9 Discovery During Registration 10 draft-ietf-sip-scvrtdisco-04 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 11, 2003. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This document defines a SIP extension header field used in 41 conjunction with responses to REGISTER requests to provide a 42 mechanism by which a registrar may inform a registering UA of a 43 service route that the UA may use to request outbound services from 44 the registrar's domain. 46 Table of Contents 48 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Discussion of Mechanism . . . . . . . . . . . . . . . . . . 4 54 4. Applicability Statement . . . . . . . . . . . . . . . . . . 5 56 5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 6.1 Procedures at the UA . . . . . . . . . . . . . . . . . . . . 6 60 6.2 Procedures at the Proxy . . . . . . . . . . . . . . . . . . 7 61 6.3 Procedures at the Registrar . . . . . . . . . . . . . . . . 8 62 6.4 Examples of Usage . . . . . . . . . . . . . . . . . . . . . 9 63 6.4.1 Example of Mechanism in REGISTER Transaction . . . . . . . . 10 64 6.4.2 Example of Mechanism in INVITE Transaction . . . . . . . . . 12 66 7. Security Considerations . . . . . . . . . . . . . . . . . . 14 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 70 Normative References . . . . . . . . . . . . . . . . . . . . 15 72 Non-Normative References . . . . . . . . . . . . . . . . . . 16 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 76 Intellectual Property and Copyright Statements . . . . . . . 17 78 1. Terminology 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC 2119 [2]. 84 2. Background 86 3GPP established a requirement for discovering home proxies during 87 SIP registration and published this requirement in [7]. The 3GPP 88 network dynamically assigns a home service proxy to each 89 address-of-record (AOR). This assignment may occur in conjunction 90 with a REGISTER operation, or out-of-band as needed to support call 91 services when the address-of-record has no registrations. This home 92 service proxy may provide both inbound (UA terminated) and outbound 93 (UA originated) services. 95 In the inbound case, the Request-URI of incoming SIP requests matches 96 the address-of-record of a user associated with the home service 97 proxy. The home service proxy then (in most cases) forwards the 98 request to the registered contact address for that AOR. A mechanism 99 for traversing required proxies between the home service proxy and 100 the registered UA is presented in [5]. 102 Outbound (UA originated) session cases raise another issue. 103 Specifically, "How does the UA know which service proxy to use and 104 how to get there?" 106 Several mechanisms were proposed in list discussions, including: 108 1. Configuration data in the UA. This raises questions of UA 109 configuration management and updating, especially if proxy 110 assignment is very dynamic, such as in load-balancing scenarios. 111 2. Use of some other protocol, such as HTTP, to get configuration 112 data from a configuration server in the home network. While 113 functional, this solution requires additional protocol engines, 114 firewall complexity, operations overhead, and significant 115 additional "over the air" traffic. 116 3. Use of lookup tables in the home network, as may be done for 117 inbound requests in some 3G networks. This has a relatively high 118 overhead in terms of database operations. 119 4. Returning a 302 response indicating the service proxy as a new 120 contact, causing the upstream node processing the 302 (ostensibly 121 the UA) to retransmit the request toward the service proxy. While 122 this shares the database operation of the previous alternative, 123 it does explicitly allow for caching the 302 response thereby 124 potentially reducing the frequency and number of database 125 operations. 127 5. Performing an operation equivalent to record-routing in a 128 REGISTER transaction between the UA and the associated registrar, 129 then storing that route in the UA and reusing it as a service 130 route on future requests originating from the UA. While 131 efficient, this constrains the service route for proxy operations 132 to be congruent with the route taken by the REGISTER message. 133 6. Returning service route information as the value of a header 134 field in the REGISTER response. While similar to the previous 135 alternative, this approach grants the ability for the registrar 136 to selectively apply knowledge about the topology of the home 137 network in constructing the service route. 139 This document defines this final alternative: returning the service 140 route information as a header field in the REGISTER response. This 141 new header field indicates a "preloaded route" that the UA may wish 142 to use if requesting services from the proxy network associated with 143 the registrar generating the response. 145 Scenario 147 UA1----P1-----| |--R-------| 148 | | | 149 P2---| DBMS 150 | | | 151 UA2-----------| |--HSP-----| 153 Figure 1 155 In this scenario, we have a "home network" containing routing proxy 156 P2, registrar R, home service proxy HSP, and database DBMS used by 157 both R and HSP. P2 represents the "edge" of the home network from a 158 SIP perspective, and might be called an "edge proxy". UA1 is an 159 external UA behind proxy P1. UA1 discovers P1 via DHCP (this is just 160 an example, and other mechanisms besides DHCP are possible). UA2 is 161 another UA on the Internet, and does not use a default outbound 162 proxy. We do not show DNS elements in this diagram, but will assume 163 their reasonable availability in the discussion. The mission is for 164 UA1 to discover HSP so that outbound requests from UA1 may be routed 165 (at the discretion of UA1) through HSP, thereby receiving outbound 166 services from HSP. 168 3. Discussion of Mechanism 170 UAs may include a Route header field in an initial request to force 171 that request to visit and potentially be serviced by one or more 172 proxies. Using such a route (called a "service route" or "preloaded 173 route") allows a UA to request services from a specific home proxy or 174 network of proxies. The open question is "how may a UA discover what 175 service route to use?" 177 This document defines a header field called "Service-Route" which can 178 contain a route vector that, if used as discussed above, will direct 179 requests through a specific sequence of proxies. A registrar may use 180 a Service-Route header field to inform a UA of a service route that, 181 if used by the UA, will provide services from a proxy or set of 182 proxies associated with that registrar. The Service-Route header 183 field may be included by a registrar in the response to a REGISTER 184 request. Consequently, a registering UA learns of a service route 185 that may be used to request services from the system it just 186 registered with. 188 The routing established by the Service-Route mechanism applies only 189 to requests originating in the user agent. That is, it applies only 190 to UA originated requests, and not to requests terminated by that UA. 192 Simply put, the registrar generates a service route for the 193 registering UA and returns it in the response to each successful 194 REGISTER request. This service route has the form of a Route header 195 field that the registering UA may use to send requests through the 196 service proxy selected by the registrar. The UA would use this route 197 by inserting it as a preloaded Route header field in requests 198 originated by the UA intended for routing through the service proxy. 200 The mechanism by which the registrar constructs the header field 201 value is specific to the local implementation and outside the scope 202 of this document. 204 4. Applicability Statement 206 The Service-Route mechanism is applicable when: 208 1. The UA registers with a registrar. 209 2. The registrar has knowledge of a service proxy that should be 210 used by the UA when requesting services from the domain of the 211 registrar. This knowledge may be a result of dynamic assignment 212 or some other mechanism outside the scope of this document. 213 3. The registrar(s) has/have sufficient knowledge of the network 214 topology, policy, and situation such that a reasonable service 215 route can be constructed. 216 4. The service route constructed by the registrar is the same for 217 all contacts associated with a single address-of-record. This 218 mechanism does not provide for contact-specific service routes. 220 5. Other mechanisms for proposing a service route to the UA are not 221 available or are inappropriate for use within the specific 222 environment. 224 Other methods may also be available by which a UA may be informed of 225 a service route. Such alternative methods are outside the scope of 226 this document. Discussion of why one might wish to assign a service 227 route during registration or when it might be appropriate to do so is 228 outside the scope of this document. 230 5. Syntax 232 The syntax for the Service-Route header field is: 234 Service-Route = "Service-Route" HCOLON sr-value *( COMMA sr-value) 236 sr-value = name-addr *( SEMI rr-param ) 238 Note that the Service-Route header field values MUST conform to the 239 syntax of a Route element as defined in [4]. As suggested therein, 240 such values MUST include the loose-routing indicator parameter ";lr" 241 for full compliance with [4]. 243 The allowable usage of header fields is described in Tables 2 and 3 244 of [4]. The following additions to this table are needed for 245 Service-Route. 247 Addition of Service-Route to SIP Table 3: 249 Header field where proxy ACK BYE CAN INV OPT REG PRA 250 _______________________________________________________________ 251 Service-Route 2xx ar - - - - - o - 253 Figure 2 255 6. Usage 257 6.1 Procedures at the UA 259 The UA performs a registration as usual. The REGISTER response may 260 contain a Service-Route header field. If so, the UA MAY store the 261 value of the Service-Route header field in an association with the 262 address-of-record for which the REGISTER transaction had registered a 263 contact. If the UA supports multiple addresses-of-record, it may be 264 able to store multiple service routes, one per address-of-record. If 265 the UA refreshes the registration, the stored value of the 266 Service-Route is updated according to the Service-Route header field 267 of the latest 200 class response. If there is no Service-Route header 268 field in the response, the UA clears any service route for that 269 address-of-record previously stored by the UA. If the re-registration 270 request is refused or if an existing registration expires and the UA 271 chooses not to re-register, the UA SHOULD discard any stored service 272 route for that address-of-record. 274 The UA MAY choose to exercise a service route for future requests 275 associated with a given address-of-record for which a service route 276 is known. If so, it uses the content of the Service-Route header 277 field as a preloaded Route header field in outgoing initial requests 278 [4]. The UA MUST preserve the order, in case there is more than one 279 Service-Route header field or header field value. 281 Loose routes may interact with routing policy in interesting ways. 282 The specifics of how the service route set integrates with any 283 locally required default route and local policy are implementation 284 dependent. For example, some devices will use locally-configured 285 explicit loose routing to reach a next-hop proxy, and others will use 286 a default outbound-proxy routing rule. However, for the result to 287 function, the combination MUST provide valid routing in the local 288 environment. In general, the service route set is appended to any 289 locally configured route needed to egress the access proxy chain. 290 Systems designers must match the service routing policy of their 291 nodes with the basic SIP routing policy in order to get a workable 292 system. 294 6.2 Procedures at the Proxy 296 The Service-Route header field is generally treated like any other 297 unknown header field by intermediate proxies. They simply forward it 298 on towards the destination. Note that, as usual, intermediate proxies 299 that need to be traversed by future requests within a dialog may 300 record-route. Proxies should not assume that they will be traversed 301 by future requests in a dialog simply because they appear in the 302 Service-Route header field. 304 There is a question of whether proxies processing a REGISTER response 305 may add themselves to the route set in the Service-Route header 306 field. While this would enable dynamic construction of service 307 routes, it has two significant problems. The first is one of 308 transparency, as seen by the registrar: Intermediate proxies could 309 add themselves without the knowledge or consent of the registrar. The 310 second problem is interaction with end-to-end security. If the 311 registrar uses S/MIME techniques to protect the REGISTER response, 312 such additions would be visible to the UA as "man in the middle" 313 alterations in the response. Consequently, intermediate proxies 314 SHOULD NOT alter the value of Service-Route in REGISTER responses, 315 and if they do, the UA MUST NOT be required to accept the alteration. 317 Additional considerations apply if a proxy is "dual homed", meaning 318 connected to two (or more) different networks such that requests are 319 received on one interface and proxied out through another network 320 interface. Proxies implementing multi-homing precisely as documented 321 in [4] record-route a request with the sending interface. When 322 processing the reply, they replace the Record-Route header field 323 value that represents the interface onto which they proxied the 324 request with a new value that represents the interface onto which 325 they will proxy the response. Consequently, the route vector seen at 326 the UAS is not the exact inverse of the route vector seen at the UAC. 327 While in itself harmless, this complicates matters for nodes that use 328 the recorded route vector (or recorded Path vector as per [5]) in the 329 determination of a service route for future use. 331 Instead of following the procedure in [4], proxies used with 332 Service-Route that are inserting Record-Route or Path header field 333 values SHOULD record not one but two route values when processing the 334 request. The first value recorded indicates the receiving interface, 335 and the second indicates the sending interface. When processing the 336 response, no modification of the recorded route is required. This 337 optimization provides for fully invertible routes that can be 338 effectively used in construction of service routes. 340 6.3 Procedures at the Registrar 342 When a registrar receives a successful REGISTER request, it MAY 343 choose to return one or more Service-Route header field(s) in the 200 344 class response. The determination(s) of whether to include these 345 header fields(s) into the 200 class response and what value(s) to 346 insert are a matter of local policy and outside the scope of this 347 document. 349 Having inserted a Service-Route header field or fields, the registrar 350 returns the 200 class response to the UA in accordance with standard 351 procedures. 353 A REGISTER operation performing a Fetching Bindings (i.e. no Contact 354 header field is present in the request) SHOULD return the same value 355 of Service-Route as returned in the corresponding previous REGISTER 356 response for the address-of-record in question. In some cases, the 357 Service-Route may be dynamically calculated by the registrar rather 358 than stored, and the decision as to whether this route should be 359 recalculated in the event of a Fetching Bindings operation is left to 360 the implementation. 362 Note: A Fetching Bindings operation could be used by the UA to 363 recover a lost value of Service-Route. Alternatively, a UA in this 364 situation could just re-REGISTER. 366 Certain network topologies MAY require a specific proxy (e.g. 367 firewall proxy) to be traversed before the home service proxy. Thus, 368 a registrar with specific knowledge of the network topology MAY 369 return more than one Service-Route header field or element in the 200 370 class response; the order is specified as top-down, meaning the 371 topmost Service-Route entry will be visited first. Such constructions 372 are implementation specific and outside the scope of this document. 374 In general, the Service-Route header field contains references to 375 elements strictly within the administrative domain of the registrar 376 and home service proxy. For example, consider a case where a user 377 leaves the "home" network and roams into a "visited" network. The 378 registrar cannot be assumed to have knowledge of the topology of the 379 visited network, so the Service-Route it returns contains elements 380 only within the home network. 382 Note that the inserted Service-Route element(s) MUST conform to the 383 syntax of a Route element as defined in [4]. As suggested therein, 384 such route elements MUST include the loose-routing indicator 385 parameter ";lr" for full compliance with [4] 387 6.4 Examples of Usage 389 We present an example in the context of the scenario presented in the 390 Background section earlier in this document. The network diagram is 391 replicated below: 393 Scenario 395 UA1----P1-----| |--R-------| 396 | | | 397 P2---| DBMS 398 | | | 399 UA2-----------| |--HSP-----| 401 Figure 3 403 6.4.1 Example of Mechanism in REGISTER Transaction 405 This example shows the message sequence for user agent UA1 406 registering to HOME.EXAMPLE.COM using registrar R. R returns a 407 Service-Route indicating that UA1 may use home service proxy 408 HSP.HOME.EXAMPLE.COM to receive outbound services from 409 HOME.EXAMPLE.COM. 411 Please note that some header fields (e.g. Content-Length) and session 412 descriptions are omitted to provide a shorter and hopefully more 413 readable presentation. 415 Message sequence for REGISTER returning Service-Route: 417 F1 Register UA1 -> P1 419 REGISTER sip:HOME.EXAMPLE.COM SIP/2.0 420 Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRAp 421 To: Lawyer 422 From: Lawyer ;tag=981211 423 Call-ID: 843817637684230@998sdasdh09 424 CSeq: 1826 REGISTER 425 Contact: 426 . . . 428 F2 Register P1 -> P2 430 REGISTER sip:HOME.EXAMPLE.COM SIP/2.0 431 Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKlJuB1mcr 432 Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRAp 433 To: Lawyer 434 From: Lawyer ;tag=981211 435 Call-ID: 843817637684230@998sdasdh09 436 CSeq: 1826 REGISTER 437 Contact: 438 . . . 440 F3 Register P2 -> R 442 REGISTER sip:HOME.EXAMPLE.COM SIP/2.0 443 Via: SIP/2.0/UDP P2.HOME.EXAMPLE.COM:5060;branch=z9hG4bKvE0R2l07o2b6T 444 Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKlJuB1mcr 445 Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRAp 446 To: Lawyer 447 From: Lawyer ;tag=981211 448 Call-ID: 843817637684230@998sdasdh09 449 CSeq: 1826 REGISTER 450 Contact: 451 . . . 453 F4 R executes Register 455 R Stores: 456 For 457 Contact: 459 F5 R calculates Service Route 461 In this example, R is statically configured to reference HSP as a 462 service route, and R also knows that P2 is used as the provider 463 edge proxy, so: 465 Service-Route: , 467 F6 Register Response r -> P2 469 SIP/2.0 200 OK 470 Via: SIP/2.0/UDP P2.HOME.EXAMPLE.COM:5060;branch=z9hG4bKvE0R2l07o2b6T 471 Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKlJuB1mcr 472 Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRAp 473 To: Lawyer ;tag=87654 474 From: Lawyer ;tag=981211 475 Call-ID: 843817637684230@998sdasdh09 476 CSeq: 1826 REGISTER 477 Contact: 478 Service-Route: , 479 . . . 481 F7 Register Response P2 -> P1 483 SIP/2.0 200 OK 484 Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKlJuB1mcr 485 Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRAp 486 To: Lawyer ;tag=87654 487 From: Lawyer ;tag=981211 488 Call-ID: 843817637684230@998sdasdh09 489 CSeq: 1826 REGISTER 490 Contact: 491 Service-Route: , 492 . . . 494 F8 Register Response P1 -> UA1 496 SIP/2.0 200 OK 497 Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRAp 498 To: Lawyer ;tag=87654 499 From: Lawyer ;tag=981211 500 Call-ID: 843817637684230@998sdasdh09 501 CSeq: 1826 REGISTER 502 Contact: 503 Service-Route: , 504 . . . 506 F9 UA1 stores service route for UA1@HOME.EXAMPLE.COM 508 Figure 4 510 6.4.2 Example of Mechanism in INVITE Transaction 512 This example shows the message sequence for an INVITE transaction 513 originating from UA1 eventually arriving at UA2 using outbound 514 services from HOME.EXAMPLE.COM. UA1 has previously registered with 515 HOME.EXAMPLE.COM and been informed of a service route through 516 HSP.HOME.EXAMPLE.COM. The service being provided by HOME.EXAMPLE.COM 517 is a "logging" service, which provides a record of the call for UA1's 518 use (perhaps the user of UA1 is an attorney who bills for calls to 519 customers). 521 Note that in this example UA1 and UA2 are assumed to be registered 522 with the same network (HOME.EXAMPLE.COM). This does not generally 523 need to be the case to use the herein described service route 524 mechanism. 526 Message sequence for INVITE using Service-Route: 528 F1 Invite UA1 -> P1 530 INVITE sip:UA2@HOME.EXAMPLE.COM SIP/2.0 531 Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKnashds7 532 To: Customer 533 From: Lawyer ;tag=456248 534 Call-ID: 38615183343@s1i1l2j6u 535 CSeq: 18 INVITE 536 Contact: 537 Route: , 538 . . . 540 Note: P1 is selected using the "outbound proxy" rule in UA1. 542 F2 Invite P1 -> P2 544 INVITE sip:UA2@HOME.EXAMPLE.COM SIP/2.0 545 Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bK34ghi7ab04 546 Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKnashds7 547 To: Customer 548 From: Lawyer ;tag=456248 549 Call-ID: 38615183343@s1i1l2j6u 550 CSeq: 18 INVITE 551 Contact: 552 Record-Route: 553 Route: , 554 . . . 556 Note: P1 has added itself to the Record Route. 558 F3 Invite P2 -> HSP 560 INVITE sip:UA2@HOME.EXAMPLE.COM SIP/2.0 561 Via: SIP/2.0/UDP P2.HOME.EXAMPLE.COM:5060;branch=z9hG4bKiokioukju908 562 Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bK34ghi7ab04 563 Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKnashds7 564 To: Customer 565 From: Lawyer ;tag=456248 566 Call-ID: 38615183343@s1i1l2j6u 567 CSeq: 18 INVITE 568 Contact: 569 Record-Route: 570 Record-Route: 571 Route: 572 . . . 574 Note: HSP is selected using a DNS lookup for HSP within HOME.EXAMPLE.COM. 575 P2 has added itself to the Record-Route. 576 P2 has removed itself from the Route. 578 F4 HSP executes service 579 HSP identifies the service to be executed from UA1's stored 580 profile. The specifics of this are outside the scope of this 581 document. For this example HSP writes a record to "Lawyer's log 582 book", then looks up the AOR "sip:UA2@HOME.EXAMPLE.COM" and discovers 583 that the current contact for UA2 is at host 584 UAADDR2.HOME.EXAMPLE.COM. This will be the Request-URI of the 585 next-hop INVITE. 587 F5 Invite HSP -> P2 589 INVITE sip:UA2@UAADDR2.HOME.EXAMPLE.COM SIP/2.0 590 Via: SIP/2.0/USP HSP.HOME.EXAMPLE.COM:5060;branch=z9hG4bKHSP10120323 591 Via: SIP/2.0/UDP P2.HOME.EXAMPLE.COM:5060;branch=z9hG4bKiokioukju908 592 Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bK34ghi7ab04 593 Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKnashds7 594 To: Customer 595 From: Lawyer ;tag=456248 596 Call-ID: 38615183343@s1i1l2j6u 597 CSeq: 18 INVITE 598 Contact: 599 Record-Route: 600 Record-Route: 601 Record-Route: 602 . . . 604 Note: P2 selected by outbound proxy rule on HSP. 605 HSP has removed itself from the Route. 607 INVITE propagates toward UA2 as usual. 609 Figure 5 611 7. Security Considerations 613 It is possible for proxies between the UA and the registrar during 614 the REGISTER transaction to modify the value of Service-Route 615 returned by the registrar, or to insert a Service-Route even when one 616 was not returned by the registrar. The consequence of such an attack 617 is that future requests made by the UA using the service route might 618 be diverted to or through a node other than would normally be 619 visited. It is also possible for proxies on the INVITE path to 620 execute many different attacks. It is therefore desirable to apply 621 transitive mutual authentication using sips: or other available 622 mechanisms in order to prevent such attacks. 624 The "sips:" URI as defined in [4] defines a mechanism by which a UA 625 may request transport-level message integrity and mutual 626 authentication. Since there is no requirement for proxies to modify 627 messages, S/MIME signed bodies may be used to provide end-to-end 628 protection for the returned value. 630 Systems using Service-Route SHOULD provide hop-by-hop message 631 integrity and mutual authentication. UAs SHOULD request this support 632 by using a "sips:" URI. Registrars returning a Service-Route MUST 633 implement end-to-end protection using S/MIME and SHOULD use S/MIME to 634 protect all such responses. UAs receiving Service-Route SHOULD 635 authenticate attached S/MIME bodies if present. 637 8. IANA Considerations 639 This document defines the SIP extension header field "Service-Route" 640 which shall be included in the registry of SIP header fields defined 641 in [4]. The change process for SIP, [6] mandates that general SIP 642 extension header fields be defined by a standards-track RFC. This 643 document provides the required definition. 645 The following is the registration for the Service-Route header field: 647 RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of 648 this specification.] 650 Header Field Name: Service-Route 652 Compact Form: none 654 Normative References 656 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 657 9, RFC 2026, October 1996. 659 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 660 Levels", BCP 14, RFC 2119, March 1997. 662 [3] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 663 2223, October 1997. 665 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 666 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 667 Session Initiation Protocol", RFC 3261, June 2002. 669 [5] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) 670 Extension Header Field for Registering Non-Adjacent Contacts", 671 RFC 3327, December 2002. 673 [6] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B. 674 Rosen, "Change Process for the Session Initiation Protocol 675 (SIP)", BCP 67, RFC 3427, December 2002. 677 Non-Normative References 679 [7] Garcia-Martin, M., "3rd-Generation Partnership Project (3GPP) 680 Release 5 requirements on the Session Initiation Protocol 681 (SIP)", draft-ietf-sipping-3gpp-r5-requirements-00 (work in 682 progress), October 2002. 684 Authors' Addresses 686 Dean Willis 687 dynamicsoft Inc. 688 3100 Independence Parkway 689 #311-164 690 Plano, TX 75075 691 US 693 Phone: +1 972 473 5455 694 EMail: dean.willis@softarmor.com 696 Bernie Hoeneisen 697 Switch 698 Limmatquai 138 699 CH-8001 Zuerich 700 Switzerland 702 Phone: +41 1 268 1515 703 EMail: hoeneisen@switch.ch, b.hoeneisen@ieee.org 704 URI: http://www.switch.ch/ 706 Intellectual Property Statement 708 The IETF takes no position regarding the validity or scope of any 709 intellectual property or other rights that might be claimed to 710 pertain to the implementation or use of the technology described in 711 this document or the extent to which any license under such rights 712 might or might not be available; neither does it represent that it 713 has made any effort to identify any such rights. Information on the 714 IETF's procedures with respect to rights in standards-track and 715 standards-related documentation can be found in BCP-11. Copies of 716 claims of rights made available for publication and any assurances of 717 licenses to be made available, or the result of an attempt made to 718 obtain a general license or permission for the use of such 719 proprietary rights by implementors or users of this specification can 720 be obtained from the IETF Secretariat. 722 The IETF invites any interested party to bring to its attention any 723 copyrights, patents or patent applications, or other proprietary 724 rights which may cover technology that may be required to practice 725 this standard. Please address the information to the IETF Executive 726 Director. 728 Full Copyright Statement 730 Copyright (C) The Internet Society (2003). All Rights Reserved. 732 This document and translations of it may be copied and furnished to 733 others, and derivative works that comment on or otherwise explain it 734 or assist in its implementation may be prepared, copied, published 735 and distributed, in whole or in part, without restriction of any 736 kind, provided that the above copyright notice and this paragraph are 737 included on all such copies and derivative works. However, this 738 document itself may not be modified in any way, such as by removing 739 the copyright notice or references to the Internet Society or other 740 Internet organizations, except as needed for the purpose of 741 developing Internet standards in which case the procedures for 742 copyrights defined in the Internet Standards process must be 743 followed, or as required to translate it into languages other than 744 English. 746 The limited permissions granted above are perpetual and will not be 747 revoked by the Internet Society or its successors or assignees. 749 This document and the information contained herein is provided on an 750 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 751 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 752 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 753 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 754 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 756 Acknowledgement 758 Funding for the RFC Editor function is currently provided by the 759 Internet Society.