idnits 2.17.1 draft-ietf-sip-record-route-fix-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 14, 2009) is 5367 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Froment 3 Internet-Draft (Unaffiliated) 4 Intended status: Standards Track C. Lebel 5 Expires: February 15, 2010 B. Bonnaerens 6 Alcatel-Lucent 7 August 14, 2009 9 Addressing Record-Route issues in the Session Initiation Protocol (SIP) 10 draft-ietf-sip-record-route-fix-10 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on February 15, 2010. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 A typical function of a Session Initiation Protocol (SIP) Proxy is to 59 insert a Record-Route header into initial, dialog creating requests 60 in order to make subsequent, in-dialog requests pass through it. 61 This header contains a SIP Uniform Resource Identifier (URI) 62 indicating where and how the subsequent requests should be sent to 63 reach the proxy. Like any SIP URI, it can contain SIP or SIPS 64 schemes, IPv4 or IPv6 addresses, and URI parameters that could 65 influence the routing such as the transport parameter (for example 66 transport=tcp), or a compression indication like "comp=sigcomp". 67 When a proxy has to change some of those parameters between its 68 incoming and outgoing interfaces (multi-homed proxies, transport 69 protocol switching or IPv4 to IPv6 scenarios...), the question arises 70 on what should be put in Record-Route header(s). It is not possible 71 to make one header have the characteristics of both interfaces at the 72 same time. This document aims to clarify these scenarios and fix 73 bugs already identified on this topic; it formally recommends the use 74 of the double Record-Route technique as an alternative to the current 75 RFC3261 text, which describes only a Record-Route rewriting solution. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 7 82 3.1. Background: multi-homed proxies . . . . . . . . . . . . . 7 83 3.2. Identified problems . . . . . . . . . . . . . . . . . . . 8 84 4. Record-Route rewriting . . . . . . . . . . . . . . . . . . . . 10 85 5. Double Record-Routing . . . . . . . . . . . . . . . . . . . . 11 86 6. Usage of Transport protocol parameter . . . . . . . . . . . . 15 87 6.1. UA implementations problems and recommendations . . . . . 15 88 6.2. Proxy implementations problems and recommendations . . . . 19 89 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 92 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 94 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 95 11.2. Informative References . . . . . . . . . . . . . . . . . . 25 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 98 1. Introduction 100 Over the years, it has been noticed in interoperability events like 101 SIPit, that many implementations had interoperability problems due to 102 various Record-Routing issues or misinterpretations of [RFC3261], in 103 particular when a change occurs between the incoming and outgoing 104 sides of a proxy: transport protocol switching, "multi-homed" proxies 105 (including IPv4 to IPv6 interface changes),... Multiple documents 106 have addressed the question, each of them generally providing an 107 adequate recommendation for its specific use case, but none of them 108 gives a general solution or provides a coherent set of 109 clarifications: 111 - [RFC3486], section 6, describes the double Record-Routing as an 112 alternative to the Record-Route rewriting in responses. This 113 document is limited in scope to the "comp=sigcomp" parameter when 114 doing compression with SIGCOMP. 116 - [RFC3608], section 6.2, recommends the usage of double Record- 117 Routing instead of the rewriting solution described in [RFC3261] 118 for "Dual-homed" proxies. Those are defined as "proxies connected 119 to two (or more) different networks such that requests are 120 received on one interface and proxied out through another network 121 interface". 123 - [I-D.ietf-sipping-v6-transition], section 3.1.1, mandates double 124 Record-Routing for multi-homed proxies doing IPv4/IPv6 125 transitions, when the proxy inserts IP addresses in the Record- 126 Route header URI. 128 The observed interoperability problems can be explained by the fact 129 that, despite these multiple documents, the RFC3261 description has 130 not been changed, and many implementations don't support extensions 131 like Service-Route ([RFC3608]) or SIGCOMP([RFC3486]). 133 This document also aims to clarify identified bug referenced in 134 [BUG664]. In particular, it takes into account [BUG664] 135 recommendation, which says that "the language that describes this, 136 needs to clearly capture that this applies to all types of different 137 interface on each side issues, including IPv4 on one side and IPv6 on 138 the other". 140 2. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [RFC2119]. 146 3. Problem statement 148 3.1. Background: multi-homed proxies 150 A multi-homed proxy is a proxy connected, like a router, to two or 151 more different networks, with an interface into each network, such 152 that traffic comes "in" one network and goes "out" a different one. 153 A simple example is shown here: 155 +-----+ 156 | UA1 | 157 +--+--+ 158 | .66 159 192.0.2.64/26 | 160 ----------------+---+-... 161 | 162 | .65 163 +-+-+ 164 | P | 165 +-+-+ 166 | .129 167 | 192.0.2.128/26 168 ...---+------+------------------ 169 | 170 | .130 171 +--+--+ 172 | UA2 | 173 +--+--+ 175 Figure 1: multi-homed proxy illustration 177 UA1 has one interface with IP address 192.0.2.66 179 The Proxy P has two interfaces and two addresses: 181 --192.0.2.65 183 --192.0.2.129 185 UA2 has one interface with address, 192.0.2.130. There is 186 potentially no IP level route between UA1 and UA2 (pinging or 187 traceroute does not work between these two hosts). They live in 188 entirely different subnetworks. But they can still exchange SIP 189 messages, because P is a SIP Proxy. This works in SIP because P can 190 apply record-routing. 192 In most cases, there is still some IP connectivity between UA1 and 193 UA2, but SIP proxy has to manage the SIP traffic between the two 194 different "sides", e.g. with two different IP addresses; or one side 195 using SIGCOMP and the other side not, etc... 197 3.2. Identified problems 199 Handling of the Record-Route header in SIP Proxies is specified by 200 following sections of [RFC3261]: 202 On the request processing side, [RFC3261], item 4 of section 16.6 203 states that: 205 "The URI placed in the Record-Route header field value MUST be a 206 SIP or SIPS URI. [...] The URI SHOULD NOT contain the transport 207 parameter unless the proxy has knowledge (such as in a private 208 network) that the next downstream element that will be in the path 209 of subsequent requests supports that transport." 211 Following this statement, it is not clear how to decide when the 212 proxy should insert the transport protocol parameter in the Record- 213 Route URI. 215 On response processing side, [RFC3261] recommends in step 8 of 216 section 16.7 that: 218 "If the selected response contains a Record-Route header field 219 value originally provided by this proxy, the proxy MAY choose to 220 rewrite the value before forwarding the response. This allows the 221 proxy to provide different URIs for itself to the next upstream 222 and downstream elements. A proxy may choose to use this mechanism 223 for any reason. For instance, it is useful for multi-homed hosts. 225 If the proxy received the request over TLS, and sent it out over a 226 non-TLS connection, the proxy MUST rewrite the URI in the Record- 227 Route header field to be a SIPS URI". 229 Note that [I-D.ietf-sip-sips] has weakened the SIP/SIPS URI rewriting 230 requirement in the Record-Route header by removing this second 231 paragraph. 233 Indeed, [RFC3261] suggests rewriting the Record-Route header in 234 responses. 236 This list highlights the utility of rewriting and double Record- 237 Routing techniques which apply for any multi-homed proxy use case, 238 whenever the proxy changes its IP address, the transport protocol or 239 the URI scheme between incoming and outgoing interfaces. Rewriting 240 and double Record-Routing are described, compared and discussed in 241 sections 4 and 5; the specific question to insert or not the 242 transport parameter in the Record-Route URI is then discussed in 243 Section 6. 245 4. Record-Route rewriting 247 As frequently outlined in IETF mailing list discussions, Record-Route 248 rewriting in responses is not the most optimal way of handling multi- 249 homed and transport protocol switching situations. Additionally, the 250 consequence of doing rewriting is that the route set seen by the 251 caller is different from the route set seen by the callee, and this 252 has at least two negative implications: 254 1) Callee cannot sign the route set, because it gets edited by the 255 proxy in the response. Consequently, end-to-end protection of the 256 route set can not be supported by the protocol. This means the 257 Internet's principles of openness and end-to-end connectivity are 258 broken. 260 2) A proxy must implement special "multi-homed" logic. During the 261 request forwarding phase, it performs an output interface calculation 262 and writes information resolving to the output interface into the URI 263 of the Record-Route header. When handling responses, the proxy must 264 inspect the Record-Route header(s), look for an input interface and 265 selectively edit them to reference the correct output interface. 266 Since this lookup has to be done for all responses forwarded by the 267 proxy, this technique implies a CPU drag. 269 Therefore this document recommends using the double Record-Route 270 approach to avoiding rewriting the Record-Route. This recommendation 271 applies to all uses of Record-Route rewriting by proxies, including 272 transport protocol switching and multi-homed proxies. 274 5. Double Record-Routing 276 The serious drawbacks of the rewriting technique explain why the 277 double Record-Routing solution has consequently been recommended in 278 SIP extensions like [RFC3486] or [RFC3608]. 280 This technique consists of inserting before any existing Record-Route 281 header, a Record-Route header with the URI reflecting to the input 282 interface, including schemes and/or URI parameters, and secondly, a 283 Record-Route header with the URI reflecting to the output interface. 284 When processing the response, no modification of the recorded route 285 is required. This is completely backward compatible with [RFC3261]. 286 Generally speaking, the time complexity will be less in double 287 Record-Routing since on processing the response, the proxy does not 288 have to do any rewrites (and thus, no searching). Moreover, the 289 handling of in-dialog requests and responses requires no special 290 handling any more. 292 When double Record-Routing, the proxy will have to handle the 293 subsequent in-dialog request(s) as a spiral, and consequently devote 294 resources to maintain transactions required to handle the spiral. 295 What is considered to be a spiralling request is explained in Section 296 6 of [RFC3261]. In order to avoid a spiral, the proxy can be smart 297 and scan an extra Route header ahead to determine whether the request 298 will spiral through it. If it does, it can optimize the second 299 spiral through itself. Even though this is an implementation 300 decision, it is much more efficient to avoid spiraling. So, this 301 means in section 16.4, "Route Information Preprocessing" [RFC3261], 302 implementors can choose that a proxy MAY remove two Route headers 303 instead of one when using the double Record-Routing. 305 The following example is an extension of the example given in 306 [I-D.ietf-sipping-v6-transition]. It illustrates a basic call flow 307 using double Record-Routing in a multi-homed IPv4 to IPv6 proxy, and 308 annotates the dialog state on each UA. In this example, proxy P1, 309 responsible for the domain biloxy.example.com, receives a request 310 from an IPv4-only upstream client. It proxies this request to an 311 IPv6-only downstream server. Proxy P1 is running on a dual-stack 312 host; on the IPv4 interface, it has an address of 192.0.2.254 and on 313 the IPv6 interface, it is configured with an address of 2001:db8::1. 314 Some mandatory SIP headers have been omitted to ease readability. 316 UA1 Proxy "P1" UA2 317 (IPv4) (IPv4/IPv6) (IPv6) 318 | | | 319 | F1 INVITE | | 320 |------------------->| F2 INVITE | 321 | |------------------->| 322 | 100 Trying | | 323 |<-------------------| | 324 | | F3 200 OK | 325 | F4 200 OK |<-------------------| 326 |<-------------------| | 327 | | | 328 | F5 ACK | | 329 |------------------->| F6 ACK | 330 | |------------------->| 331 | | | 332 | | F7 BYE | 333 | F8 BYE |<-------------------| 334 |<-------------------| | 336 Figure 2: IPv4 to IPv6 multi-homed proxy illustration 338 UA1 P1 UA2 340 F1 INVITE UA1 -> P1 (192.0.2.254:5060) 342 INVITE sip:bob@biloxi.example.com SIP/2.0 343 Route: 344 From: Alice ;tag=1234 345 To: Bob 346 Contact: 348 F2 INVITE P1 (2001:db8::1) -> UA2 350 INVITE sip:bob@biloxi.example.com SIP/2.0 351 Record-Route: 352 Record-Route: 353 From: Alice ;tag=1234 354 To: Bob 355 Contact: 357 Dialog State at UA2: 358 Local URI = sip:bob@biloxi.example.com 359 Remote URI = sip:alice@atlanta.example.com 360 Remote target = sip:alice@192.0.2.1 361 Route Set = sip:[2001:db8::1];lr 362 sip:192.0.2.254:5060:lr 364 F3 200 OK UA2 -> P1 (2001:db8::1) 366 SIP/2.0 200 OK 367 Record-Route: 368 Record-Route: 369 From: Alice ;tag=1234 370 To: Bob ;tag=4567 371 Contact: 373 F4 200 OK P1 -> UA1 375 SIP/2.0 200 OK 376 Record-Route: 377 Record-Route: 378 From: Alice ;tag=1234 379 To: Bob ;tag=4567 380 Contact: 382 Dialog State at UA1: 383 Local URI = sip:alice@atlanta.example.com 384 Remote URI = sip:bob@biloxi.example.com 385 Remote target = sip:bob@[2001:db8::33] 386 Route Set = sip:192.0.2.254:5060:lr 387 sip:[2001:db8::1];lr 389 F5 ACK UA1 -> P1 (192.0.2.254:5060) 391 ACK sip:bob@[2001:db8::33] SIP/2.0 392 Route: 393 Route: 394 From: Alice ;tag=1234 395 To: Bob ;tag=4567 397 F6 ACK P1 (2001:db8::1) -> UA2 399 ACK sip:bob@[2001:db8::33] SIP/2.0 400 From: Alice ;tag=1234 401 To: Bob ;tag=4567 402 (both Route headers have been removed by the proxy) 404 F7 BYE UA2 -> P1 (2001:db8::1) 406 BYE sip:alice@192.0.2.1 SIP/2.0 407 Route: 408 Route: 409 From: Bob ;tag=4567 410 To: Alice ;tag=1234 412 F8 BYE P1 (192.0.2.254:5060) -> UA1 414 BYE sip:alice@192.0.2.1 SIP/2.0 415 From: Bob ;tag=4567 416 To: Alice ;tag=1234 418 Figure 3: Multi-homed IPv4 to IPv6 double Record-Routing illustration 420 6. Usage of Transport protocol parameter 422 This section describes a set of problems that are related to the 423 usage of transport protocol URI parameter in the Record-Route header. 424 In some circumstances interoperability problems occur because it is 425 not clear whether or not to include the transport parameter on the 426 URI of the Record-Route header. This was identified as a frequent 427 problem in past SIPit events. 429 [RFC3261], step 8 of section 16.7 says: 431 "The URI SHOULD NOT contain the transport parameter unless the 432 proxy has knowledge (such as in a private network) that the next 433 downstream element that will be in the path of subsequent requests 434 supports that transport." 436 The preceding seems to confuse implementors, resulting in proxies 437 that insert a single Record-Route without a transport URI parameter, 438 resulting in the problems described in this section. 440 6.1. UA implementations problems and recommendations 442 Consider the following scenario: a SIP proxy, doing TCP to UDP 443 transport protocol switching. 445 In this example, proxy P1, responsible for the domain 446 biloxy.example.com, receives a request from Alice UA1 which uses TCP. 447 It proxies this request to Bob UA2 which registered with a Contact 448 specifying UDP as transport protocol. Thus, P1 receives an initial 449 request from Alice over TCP and forwards it to Bob over UDP. For 450 subsequent requests, it is expected that TCP could continue to be 451 used between Alice and P1, and UDP between P1 and Bob, but this can 452 not happen if a numeric IP address is used and no transport parameter 453 is set on Record-Route URI. This happens because of procedures 454 described in[RFC3263]. Some mandatory SIP headers have been omitted 455 to ease readability. 457 Alice UA1 ===== TCP ===== Proxy P1 ===== UDP ===== Bob UA2 458 | | | 459 | F1 INVITE | | 460 |----------------------->| F2 INVITE | 461 | |------------------------>| 462 | 100 Trying | | 463 |<-----------------------| | 464 | | F3 200 OK | 465 | F4 200 OK |<------------------------| 466 |<-----------------------| | 467 | | | 468 | F5 ACK | | 469 |---(sent over UDP) X--->| ACK | 470 | |------------------------>| 471 | | | 472 | | F6 BYE | 473 | BYE |<------------------------| 474 |<-----------------------| | 476 Figure 4: TCP to UDP transport protocol switching issue illustration 478 F1 INVITE UA1 -> P1 (192.0.2.1/tcp) 480 INVITE sip:bob@biloxi.example.com SIP/2.0 481 Route: 482 From: Alice ;tag=1234 483 To: Bob 484 Contact: 486 F2 INVITE P1 -> UA2 (ua2.biloxi.example.com/udp) 488 INVITE sip:bob@ua2.biloxi.example.com;transport=udp SIP/2.0 489 Record-Route: (NO transport param) 490 From: Alice ;tag=1234 491 To: Bob 492 Contact: 494 Dialog State at UA2: 495 Local URI = sip:bob@biloxi.example.com 496 Remote URI = sip:alice@atlanta.example.com 497 Remote target = sip:alice@ua1.atlanta.example.com;transport=tcp 498 Route Set = sip:192.0.2.1;lr 500 F3 200 OK UA2 -> P1 (192.0.2.1/udp) 502 SIP/2.0 200 OK 503 Record-Route: 504 From: Alice ;tag=1234 505 To: Bob ;tag=4567 506 Contact: 508 F4 200 OK P1 -> UA1 (ua1.atlanta.example.com/tcp) 510 SIP/2.0 200 OK 511 Record-Route: 512 From: Alice ;tag=1234 513 To: Bob ;tag=4567 514 Contact: 516 Dialog State at UA1: 517 Local URI = sip:alice@atlanta.example.com 518 Remote URI = sip:bob@biloxi.example.com 519 Remote target = sip:bob@ua2.biloxi.example.com 520 Route Set = sip:192.0.2.1;lr 522 F5 ACK UA1 -> P1 (192.0.2.1/udp) 524 ACK sip:bob@ua2.biloxi.example.com SIP/2.0 525 Route: 526 From: Alice ;tag=1234 527 To: Bob ;tag=4567 529 F6 BYE UA2 -> P1 (192.0.2.1/udp) 531 BYE sip:alice@ua1.atlanta.example.com;transport=tcp SIP/2.0 532 Route: 533 From: Bob ;tag=4567 534 To: Alice ;tag=1234 536 Figure 5: TCP to UDP transport protocol switching issue description 538 Since the proxy P1 does not insert any transport parameter in the 539 Record-Route URI, subsequent in-dialog requests of UA1, like the ACK 540 sent in F5, will be sent according to the behaviour specified in 541 section 12.2 (requests within a Dialog) of [RFC3261]. That means 542 that the routeset is used, and then, applying [RFC3263], the Route 543 "sip:192.0.2.1" will resolve to a UDP transport by default (since no 544 transport parameter is present here), and no NAPTR request will be 545 performed since this is a numeric IP address. In general, the 546 interoperability problems arise when UA1 is trying to send the ACK: 547 it is not ready to change its transport protocol for a mid-dialog 548 request and just fails to do so, requiring the proxy implementor to 549 insert the transport protocol in the Record-Route URI. 551 What happens if the proxy had record-routed its logical name 552 (biloxi.example.com)? If UA1 and UA2 use [RFC3263] procedures, it 553 would resolve to the same transport on both sides and only if the 554 resulting transport would be UDP transport protocol switching would 555 have been avoided and the scenario would work. However, if one of 556 the UAs sends an initial request using a different transport than the 557 one retrieved from DNS, this scenario is still problematic. 559 In practice, there are multiple situations where UAs implementations 560 don't use logical names and NAPTR records when sending an initial 561 request to a proxy. This happens, for instance, when: 563 1) UAs offer the ability to "choose" the transport to be used for 564 initial requests, even if they support [RFC3263]. This is a frequent 565 UA functionality which is justified by the following use cases: 567 - when it is not possible to change DNS server configuration and the 568 implementation doesn't support all the transport protocols that could 569 be configured by default in DNS (e.g.: TLS). 571 - when the end-user wants to choose his transport protocol for 572 whatever reason. e.g: need to force TCP, avoiding UDP / congestion, 573 retransmissions or fragmentation... 575 This ability to force the transport protocol in UA for initial 576 requests SHOULD be avoided: selecting the transport protocol in the 577 configuration of an outbound proxy means that [RFC3263] procedure is 578 bypassed for initial requests. As a consequence, if the proxy 579 Record-Routed with no transport parameter as recommended in 580 [RFC3261], the UA will anyway be forced to use the [RFC3263]- 581 preferred transport for subsequent requests, which leads to the 582 problematic scenario described in Figure 4. 584 2) UAs decide to always keep the same transport for a given dialog. 585 This choice is erratic, since if the proxy is not record-routing, the 586 callee MAY receive the subsequent request through a transport that is 587 not the one put in its Contact. If a UA really wants to avoid 588 transport protocol switching between initial and subsequent request, 589 it SHOULD rely on DNS records for that, and thus it SHOULD avoid 590 configuring statically the outbound proxy with a numeric IP address: 591 a logical name, with no transport parameter SHOULD be used instead. 593 3) UAs don't support [RFC3263] at all, or don't have any DNS server 594 available. In that case, as illustrated previously, forcing UA1 to 595 switch from TCP to UDP between initial request and subsequent 596 request(s) is clearly not the desired default behaviour, and it 597 typically leads to interoperability problems. UA implementations 598 SHOULD then be ready to change the transport protocol between initial 599 and subsequent requests. In theory, any UA or proxy using UDP must 600 also be prepared to use TCP for requests that exceed the size limit 601 of path MTU, as described in section 18.1.1 of [RFC3261]. 603 6.2. Proxy implementations problems and recommendations 605 In order to prevent UA implementation problems, and to maintain a 606 reasonable level of interoperability, the situation can be improved 607 on proxy side. Thus, if the transport protocol changed between its 608 incoming and outgoing sides, the proxy SHOULD use the double Record- 609 Route technique and SHOULD add a transport parameter to each of the 610 Record-Route URIs it inserts. When TLS is used on the transport on 611 either side of the proxy, the URI placed in the Record-Route header 612 field MUST encode a next-hop that will be reached using TLS. There 613 are two ways for this to work. The first way is for the URI placed 614 in the Record-Route to be a SIPS URI. The second is for the URI 615 placed in the Record-Route to be constructed such that application of 616 [RFC3263] resolution procedures to that URI results in TLS being 617 selected. Proxies compliant with this specification MUST NOT use a 618 "transport=tls" parameter on the URI placed in the Record-Route 619 because the "transport=tls" usage was deprecated by [RFC3261]. 620 Record-Route Rewriting MAY also be used. However, the recommendation 621 to put a transport protocol parameter on Record-Route URI does not 622 apply when the proxy has changed the transport protocol due to the 623 size of UDP requests as per section 18.1.1 of [RFC3261]. As an 624 illustration of previous example, it means one of the following 625 processing will be performed: 627 - Double Record-Routing: the proxy puts two Record-Route headers. 628 The first one is set, in this example, to Record-Route: , the second one to Record-Route: with no transport, or with transport=udp, which 631 basically means the same thing. 633 - Record-Route rewriting on responses: in the INVITE request sent in 634 F2, proxy puts the outgoing transport protocol in the transport 635 parameter of Record-Route URI. Doing so, UA2 will correctly send its 636 BYE request in F6 using the same transport protocol as previous 637 messages of the same dialog. Proxy rewrites the Record-Route when 638 processing the 200 OK response, changing "on the fly" the transport 639 parameter to "transport=tcp", so that the Route set will appear to be 640 for UA1 and for UA2. 643 It is a common practice in proxy implementations to support double 644 Record-Route AND to insert the transport parameter in the Record- 645 Route URI. This practice is acceptable as long as all SIP elements 646 that may be in the path of subsequent requests support that 647 transport. This restriction needs an explanation: let's imagine you 648 have two proxies P1 at "p1.biloxi.example.com" and P2 on the path of 649 an initial request. P1 is record-routing and changes the transport 650 from UDP to SCTP because P2 URI resolves to SCTP transport applying 651 [RFC3263]. Consequently, the proxy P1 inserts two Record-Route 652 headers: 654 Record-Route: and 656 Record-Route: . 658 The problem arises if P2 is not record-routing, because the SIP 659 element downstream of P2 will be asked to reach P1 using SCTP 660 transport protocol for any subsequent, in-dialog request from the 661 callee, and this downstream SIP element may not support that 662 transport. 664 In order to handle this situation, this document recommends that a 665 proxy SHOULD apply the double Record-Routing technique as soon as it 666 changes the transport protocol between its incoming and outgoing 667 sides. If proxy P2 in the example above would follow this 668 recommendation, it would perform double Record-Routing and the 669 downstream element would not be forced to send requests over a 670 transport it does not support. 672 By extension, a proxy SHOULD also insert a Record-Route header for 673 any multi-homed situation (as the ones described in this document; 674 scheme changes, sigcomp, IPv4/IPv6, transport changes...) that may 675 impact the processing of proxies being on the path of subsequent 676 requests. 678 7. Conclusion 680 As a conclusion of this document, it is to notice that: 682 - Record-Route rewriting is presented as a technique that MAY be 683 used, with the drawbacks outlined in section 4. 685 - Double Record-Routing is presented as the technique that SHOULD 686 be used, and is documented in section 5. 688 - Record-Route header interoperability problems on transport 689 protocol switching scenarios have been outlined and described in 690 section 6. This last section gives some recommendations to UA and 691 proxy implementations to improve the situation. Proxies SHOULD 692 use Double Record-Routing for any multi-homed situation that MAY 693 impact the further processing, and SHOULD put transport protocol 694 parameters on Record-Route URI in some circumstances. UAs SHOULD 695 NOT offer options to overwrite the transport for initial requests. 696 Further, UAs SHOULD rely on DNS to express their desired transport 697 and SHOULD avoid IP addresses with transport parameters in this 698 case. Finally UAs SHOULD be ready to switch transport between the 699 initial request and further in-dialog messages. 701 8. IANA Considerations 703 This document does not require any actions by IANA. 705 9. Security Considerations 707 The recommendations in this document describe a way to use the 708 existing protocol specified in RFC3261 rather than introducing any 709 new protocol mechanism. As such, they do not introduce any new 710 security concerns, but additional consideration of already existing 711 concerns is warranted. In particular, when a message is transiting 712 two interfaces, the double Record-Route technique will carry 713 information about both interfaces to each of the involved endpoints 714 (and any intermediaries between this proxy and those endpoints), 715 where the rewriting technique would only expose information about the 716 interface closest to each given endpoint. If issues such as topology 717 hiding or privacy (as described in [RFC3323]) are a concern, the URI 718 values placed in the Record-Route for each interface should be 719 carefully constructed to avoid exposing more information than was 720 intended. 722 10. Acknowledgments 724 Dean Willis who contributed, through the mailing lists, to most of 725 the problem statement elements. Vijay K. Gurbani who provided 726 important references and substantial modifications. 728 Joel Repiquet, Robert Sparks, Jonathan Rosenberg, Cullen Jennings, 729 Juha Heinanen, Paul Kyzivat, Nils Ohlmeier, Tim Polk, Francois Audet, 730 Adrian Farrel, Ralph Droms, Tom Batsele, Yannick Bourget, Keith Drage 731 and John Elwell for their reviews and comments. 733 11. References 735 11.1. Normative References 737 [I-D.ietf-sip-sips] 738 Audet, F., "The use of the SIPS URI Scheme in the Session 739 Initiation Protocol (SIP)", draft-ietf-sip-sips-09 (work 740 in progress), November 2008. 742 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 743 Requirement Levels", March 1997. 745 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 746 A., Peterson, J., Sparks, R., Handley, M., and E. 747 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 748 June 2002. 750 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 751 Protocol (SIP): Locating SIP Servers", RFC 3263, 752 June 2002. 754 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 755 Initiation Protocol (SIP)", RFC 3323, November 2002. 757 11.2. Informative References 759 [BUG664] Sparks, RS., "Bug 664: Double record routing, 760 http://bugs.sipit.net/show_bug.cgi?id=664", October 2002. 762 [I-D.ietf-sipping-v6-transition] 763 Camarillo, G., "IPv6 Transition in the Session Initiation 764 Protocol (SIP)", draft-ietf-sipping-v6-transition-07 (work 765 in progress), August 2007. 767 [RFC3486] Camarillo, G., "Compressing the Session Initiation 768 Protocol (SIP)", RFC 3486, February 2003. 770 [RFC3608] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 771 (SIP) Extension Header Field for Service Route Discovery 772 During Registration", RFC 3608, October 2003. 774 Authors' Addresses 776 Thomas Froment 777 (Unaffiliated) 778 7 Clos du Perray 779 Longpont sur Orge 91310 780 France 782 Email: tfroment@yahoo.com 784 Christophe Lebel 785 Alcatel-Lucent 786 Lieu dit Le Mail 787 Orvault 44708 788 France 790 Email: Christophe.Lebel@alcatel-lucent.fr 792 Ben Bonnaerens 793 Alcatel-Lucent 794 Copernicuslaan 50 795 Antwerpen 2018 796 Belgium 798 Email: ben.bonnaerens@alcatel-lucent.be