summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5658.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5658.txt')
-rw-r--r--doc/rfc/rfc5658.txt1011
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc5658.txt b/doc/rfc/rfc5658.txt
new file mode 100644
index 0000000..4d4bf51
--- /dev/null
+++ b/doc/rfc/rfc5658.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group T. Froment
+Request for Comments: 5658 Tech-invite
+Category: Standards Track C. Lebel
+ B. Bonnaerens
+ Alcatel-Lucent
+ October 2009
+
+
+ Addressing Record-Route Issues in
+ the Session Initiation Protocol (SIP)
+
+Abstract
+
+ A typical function of a Session Initiation Protocol (SIP) Proxy is to
+ insert a Record-Route header into initial, dialog-creating requests
+ in order to make subsequent, in-dialog requests pass through it.
+ This header contains a SIP Uniform Resource Identifier (URI) or SIPS
+ (secure SIP) URI indicating where and how the subsequent requests
+ should be sent to reach the proxy. These SIP or SIPS URIs can
+ contain IPv4 or IPv6 addresses and URI parameters that could
+ influence the routing such as the transport parameter (for example,
+ transport=tcp), or a compression indication like "comp=sigcomp".
+ When a proxy has to change some of those parameters between its
+ incoming and outgoing interfaces (multi-homed proxies, transport
+ protocol switching, or IPv4 to IPv6 scenarios, etc.), the question
+ arises on what should be put in Record-Route header(s). It is not
+ possible to make one header have the characteristics of both
+ interfaces at the same time. This document aims to clarify these
+ scenarios and fix bugs already identified on this topic; it formally
+ recommends the use of the double Record-Route technique as an
+ alternative to the current RFC 3261 text, which describes only a
+ Record-Route rewriting solution.
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+
+
+
+
+
+
+
+
+
+
+Froment, et al. Standards Track [Page 1]
+
+RFC 5658 SIP Record-Route Fix October 2009
+
+
+Copyright Notice
+
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Terminology .....................................................3
+ 3. Problem Statement ...............................................4
+ 3.1. Background: Multi-Homed Proxies ............................4
+ 3.2. Identified Problems ........................................5
+ 4. Record-Route Rewriting ..........................................6
+ 5. Double Record-Routing ...........................................6
+ 6. Usage of Transport Protocol Parameter ..........................10
+ 6.1. UA Implementation Problems and Recommendations ............10
+ 6.2. Proxy Implementation Problems and Recommendations .........14
+ 7. Conclusion .....................................................15
+ 8. Security Considerations ........................................16
+ 9. Acknowledgments ................................................16
+ 10. References ....................................................17
+ 10.1. Normative References .....................................17
+ 10.2. Informative References ...................................17
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Froment, et al. Standards Track [Page 2]
+
+RFC 5658 SIP Record-Route Fix October 2009
+
+
+1. Introduction
+
+ Over the years, it has been noticed in interoperability events like
+ SIPit, that many implementations had interoperability problems due to
+ various Record-Routing issues or misinterpretations of [RFC3261]; in
+ particular, when a change occurs between the incoming and outgoing
+ sides of a proxy: transport protocol switching, "multi-homed" proxies
+ (including IPv4 to IPv6 interface changes), etc. Multiple documents
+ have addressed the question, each of them generally providing an
+ adequate recommendation for its specific use case, but none of them
+ gives a general solution or provides a coherent set of
+ clarifications:
+
+ - [RFC3486], Section 6, describes the double Record-Routing as an
+ alternative to the Record-Route rewriting in responses. This
+ document is limited in scope to the "comp=sigcomp" parameter
+ when doing compression with Signalling Compression (SIGCOMP).
+
+ - [RFC3608], Section 6.2, recommends the usage of double Record-
+ Routing instead of the rewriting solution described in [RFC3261]
+ for "Dual-homed" proxies. Those are defined as "proxies
+ connected to two (or more) different networks such that requests
+ are received on one interface and proxied out through another
+ network interface".
+
+ - Section 3.1.1 of [V6Tran] mandates double Record-Routing for
+ multi-homed proxies doing IPv4/IPv6 transitions, when the proxy
+ inserts IP addresses in the Record-Route header URI.
+
+ The observed interoperability problems can be explained by the fact
+ that, despite these multiple documents, the RFC 3261 description has
+ not been changed, and many implementations don't support extensions
+ like Service-Route ([RFC3608]) or SIGCOMP ([RFC3486]).
+
+ This document also aims to clarify an identified bug referenced in
+ [BUG664]. In particular, it takes into account the [BUG664]
+ recommendation, which says that "the language that describes this,
+ needs to clearly capture that this applies to all types of different
+ interface on each side issues, including IPv4 on one side and IPv6 on
+ the other".
+
+2. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+
+
+
+
+Froment, et al. Standards Track [Page 3]
+
+RFC 5658 SIP Record-Route Fix October 2009
+
+
+3. Problem Statement
+
+3.1. Background: Multi-Homed Proxies
+
+ A multi-homed proxy is a proxy connected, like a router, to two or
+ more different networks, with an interface into each network, such
+ that traffic comes "in" one network and goes "out" a different one.
+ A simple example is shown here:
+
+ +-----+
+ | UA1 |
+ +--+--+
+ | .66
+ 192.0.2.64/26 |
+ ----------------+---+-...
+ |
+ | .65
+ +-+-+
+ | P |
+ +-+-+
+ | .129
+ | 192.0.2.128/26
+ ...---+------+------------------
+ |
+ | .130
+ +--+--+
+ | UA2 |
+ +--+--+
+
+ Figure 1: Multi-Homed Proxy Illustration
+
+ UA1 has one interface with IP address 192.0.2.66.
+
+ The Proxy P has two interfaces and two addresses:
+
+ --192.0.2.65
+
+ --192.0.2.129
+
+ UA2 has one interface with address, 192.0.2.130. There is
+ potentially no IP-level route between UA1 and UA2 (pinging or
+ traceroute does not work between these two hosts). They live in
+ entirely different subnetworks. But they can still exchange SIP
+ messages, because P is a SIP Proxy. This works in SIP because P can
+ apply Record-Routing.
+
+
+
+
+
+
+Froment, et al. Standards Track [Page 4]
+
+RFC 5658 SIP Record-Route Fix October 2009
+
+
+ In most cases, there is still some IP connectivity between UA1 and
+ UA2, but SIP proxy has to manage the SIP traffic between the two
+ different "sides", e.g., with two different IP addresses, or one side
+ using SIGCOMP and the other side not, etc.
+
+3.2. Identified Problems
+
+ Handling of the Record-Route header in SIP Proxies is specified by
+ following sections of [RFC3261]:
+
+ On the request processing side, [RFC3261], item 4 of Section 16.6
+ states that:
+
+ The URI placed in the Record-Route header field value MUST be a
+ SIP or SIPS URI. [...] The URI SHOULD NOT contain the transport
+ parameter unless the proxy has knowledge (such as in a private
+ network) that the next downstream element that will be in the path
+ of subsequent requests supports that transport.
+
+ Following this statement, it is not clear how to decide when the
+ proxy should insert the transport protocol parameter in the Record-
+ Route URI.
+
+ On the response processing side, [RFC3261] recommends in step 8 of
+ Section 16.7 that:
+
+ If the selected response contains a Record-Route header field
+ value originally provided by this proxy, the proxy MAY choose to
+ rewrite the value before forwarding the response. This allows the
+ proxy to provide different URIs for itself to the next upstream
+ and downstream elements. A proxy may choose to use this mechanism
+ for any reason. For instance, it is useful for multi-homed hosts.
+
+ If the proxy received the request over Transport Layer Security
+ (TLS), and sent it out over a non-TLS connection, the proxy MUST
+ rewrite the URI in the Record-Route header field to be a SIPS URI.
+
+ Note that [RFC5630] has weakened the SIP/SIPS URI rewriting
+ requirement in the Record-Route header by removing this second
+ paragraph.
+
+ Indeed, [RFC3261] suggests rewriting the Record-Route header in
+ responses.
+
+ This list highlights the utility of rewriting and double Record-
+ Routing techniques that apply for any multi-homed proxy use case:
+ whenever the proxy changes its IP address, the transport protocol, or
+ the URI scheme between incoming and outgoing interfaces. Rewriting
+
+
+
+Froment, et al. Standards Track [Page 5]
+
+RFC 5658 SIP Record-Route Fix October 2009
+
+
+ and double Record-Routing are described, compared, and discussed in
+ Sections 4 and 5; the specific question of whether or not to insert
+ the transport parameter in the Record-Route URI is then discussed in
+ Section 6.
+
+4. Record-Route Rewriting
+
+ As frequently outlined in IETF mailing list discussions, Record-Route
+ rewriting in responses is not the optimal way of handling multi-
+ homed and transport protocol switching situations. Additionally, the
+ consequence of doing rewriting is that the route set seen by the
+ caller is different from the route set seen by the callee, and this
+ has at least two negative implications:
+
+ 1) The callee cannot sign the route set, because it gets edited by
+ the proxy in the response. Consequently, end-to-end protection of
+ the route set cannot be supported by the protocol. This means the
+ Internet's principles of openness and end-to-end connectivity are
+ broken.
+
+ 2) A proxy must implement special "multi-homed" logic. During the
+ request forwarding phase, it performs an output interface
+ calculation and writes information resolving to the output
+ interface into the URI of the Record-Route header. When handling
+ responses, the proxy must inspect the Record-Route header(s), look
+ for an input interface, and selectively edit them to reference the
+ correct output interface. Since this lookup has to be done for
+ all responses forwarded by the proxy, this technique implies a CPU
+ drag.
+
+ Therefore, this document recommends using the double Record-Route
+ approach to avoid rewriting the Record-Route. This recommendation
+ applies to all uses of Record-Route rewriting by proxies, including
+ transport protocol switching and multi-homed proxies.
+
+5. Double Record-Routing
+
+ The serious drawbacks of the rewriting technique explain why the
+ double Record-Routing solution has consequently been recommended in
+ SIP extensions like [RFC3486] or [RFC3608].
+
+ This technique consists of inserting before any existing Record-Route
+ header, a Record-Route header with the URI reflecting to the input
+ interface, including schemes and/or URI parameters, and secondly, a
+ Record-Route header with the URI reflecting to the output interface.
+ When processing the response, no modification of the recorded route
+ is required. This is completely backward compatible with [RFC3261].
+ Generally speaking, the time complexity will be less in double
+
+
+
+Froment, et al. Standards Track [Page 6]
+
+RFC 5658 SIP Record-Route Fix October 2009
+
+
+ Record-Routing since, on processing the response, the proxy does not
+ have to do any rewrites (and thus, no searching). Moreover, the
+ handling of in-dialog requests and responses requires no special
+ handling anymore.
+
+ When double Record-Routing, the proxy will have to handle the
+ subsequent in-dialog request(s) as a spiral, and consequently devote
+ resources to maintain transactions required to handle the spiral.
+ What is considered to be a spiraling request is explained in Section
+ 6 of [RFC3261]. In order to avoid a spiral, the proxy can be smart
+ and scan an extra Route header ahead to determine whether the request
+ will spiral through it. If it does, it can optimize the second
+ spiral through itself. Even though this is an implementation
+ decision, it is much more efficient to avoid spiraling. So, this
+ means, in Section 16.4, "Route Information Preprocessing" [RFC3261],
+ implementors can choose that a proxy MAY remove two Route headers
+ instead of one when using the double Record-Routing.
+
+ The following example is an extension of the example given in
+ [V6Tran]. It illustrates a basic call flow using double Record-
+ Routing in a multi-homed IPv4 to IPv6 proxy, and annotates the dialog
+ state on each User Agent (UA). In this example, proxy P1,
+ responsible for the domain biloxy.example.com, receives a request
+ from an IPv4-only upstream client. It proxies this request to an
+ IPv6-only downstream server. Proxy P1 is running on a dual-stack
+ host; on the IPv4 interface, it has an address of 192.0.2.254. On
+ the IPv6 interface, it is configured with an address of 2001:db8::1.
+ Some mandatory SIP headers have been omitted to ease readability.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Froment, et al. Standards Track [Page 7]
+
+RFC 5658 SIP Record-Route Fix October 2009
+
+
+ UA1 Proxy "P1" UA2
+ (IPv4) (IPv4/IPv6) (IPv6)
+ | | |
+ | F1 INVITE | |
+ |------------------->| F2 INVITE |
+ | |------------------->|
+ | 100 Trying | |
+ |<-------------------| |
+ | | F3 200 OK |
+ | F4 200 OK |<-------------------|
+ |<-------------------| |
+ | | |
+ | F5 ACK | |
+ |------------------->| F6 ACK |
+ | |------------------->|
+ | | |
+ | | F7 BYE |
+ | F8 BYE |<-------------------|
+ |<-------------------| |
+
+ Figure 2: IPv4 to IPv6 Multi-Homed Proxy Illustration
+
+
+ F1 INVITE UA1 -> P1 (192.0.2.254:5060)
+
+ INVITE sip:bob@biloxi.example.com SIP/2.0
+ Route: <sip:192.0.2.254:5060;lr>
+ From: Alice <sip:alice@atlanta.example.com>;tag=1234
+ To: Bob <sip:bob@biloxi.example.com>
+ Contact: <sip:alice@192.0.2.1>
+
+ F2 INVITE P1 (2001:db8::1) -> UA2
+
+ INVITE sip:bob@biloxi.example.com SIP/2.0
+ Record-Route: <sip:[2001:db8::1];lr>
+ Record-Route: <sip:192.0.2.254:5060;lr>
+ From: Alice <sip:alice@atlanta.example.com>;tag=1234
+ To: Bob <sip:bob@biloxi.example.com>
+ Contact: <sip:alice@192.0.2.1>
+
+ Dialog State at UA2:
+ Local URI = sip:bob@biloxi.example.com
+ Remote URI = sip:alice@atlanta.example.com
+ Remote target = sip:alice@192.0.2.1
+ Route Set = sip:[2001:db8::1];lr
+ sip:192.0.2.254:5060:lr
+
+
+
+
+
+Froment, et al. Standards Track [Page 8]
+
+RFC 5658 SIP Record-Route Fix October 2009
+
+
+ F3 200 OK UA2 -> P1 (2001:db8::1)
+
+ SIP/2.0 200 OK
+ Record-Route: <sip:[2001:db8::1];lr>
+ Record-Route: <sip:192.0.2.254:5060;lr>
+ From: Alice <sip:alice@atlanta.example.com>;tag=1234
+ To: Bob <sip:bob@biloxi.example.com>;tag=4567
+ Contact: <sip:bob@[2001:db8::33]>
+
+ F4 200 OK P1 -> UA1
+
+ SIP/2.0 200 OK
+ Record-Route: <sip:[2001:db8::1];lr>
+ Record-Route: <sip:192.0.2.254:5060;lr>
+ From: Alice <sip:alice@atlanta.example.com>;tag=1234
+ To: Bob <sip:bob@biloxi.example.com>;tag=4567
+ Contact: <sip:bob@[2001:db8::33]>
+
+ Dialog State at UA1:
+ Local URI = sip:alice@atlanta.example.com
+ Remote URI = sip:bob@biloxi.example.com
+ Remote target = sip:bob@[2001:db8::33]
+ Route Set = sip:192.0.2.254:5060:lr
+ sip:[2001:db8::1];lr
+
+ F5 ACK UA1 -> P1 (192.0.2.254:5060)
+
+ ACK sip:bob@[2001:db8::33] SIP/2.0
+ Route: <sip:192.0.2.254:5060:lr>
+ Route: <sip:[2001:db8::1];lr>
+ From: Alice <sip:alice@atlanta.example.com>;tag=1234
+ To: Bob <sip:bob@biloxi.example.com>;tag=4567
+
+ F6 ACK P1 (2001:db8::1) -> UA2
+
+ ACK sip:bob@[2001:db8::33] SIP/2.0
+ From: Alice <sip:alice@atlanta.example.com>;tag=1234
+ To: Bob <sip:bob@biloxi.example.com>;tag=4567
+ (both Route headers have been removed by the proxy)
+
+ F7 BYE UA2 -> P1 (2001:db8::1)
+
+ BYE sip:alice@192.0.2.1 SIP/2.0
+ Route: <sip:[2001:db8::1];lr>
+ Route: <sip:192.0.2.254:5060:lr>
+ From: Bob <sip:bob@biloxi.example.com>;tag=4567
+ To: Alice <sip:alice@atlanta.example.com>;tag=1234
+
+
+
+
+Froment, et al. Standards Track [Page 9]
+
+RFC 5658 SIP Record-Route Fix October 2009
+
+
+ F8 BYE P1 (192.0.2.254:5060) -> UA1
+
+ BYE sip:alice@192.0.2.1 SIP/2.0
+ From: Bob <sip:bob@biloxi.example.com>;tag=4567
+ To: Alice <sip:alice@atlanta.example.com>;tag=1234
+
+ Figure 3: Multi-Homed IPv4 to IPv6 Double Record-Routing Illustration
+
+6. Usage of Transport Protocol Parameter
+
+ This section describes a set of problems that is related to the usage
+ of transport protocol URI parameters in the Record-Route header. In
+ some circumstances, interoperability problems occur because it is not
+ clear whether or not to include the transport parameter on the URI of
+ the Record-Route header. This was identified as a frequent problem
+ in past SIPit events.
+
+ [RFC3261], step 8 of Section 16.7 says:
+
+ The URI SHOULD NOT contain the transport parameter unless the
+ proxy has knowledge (such as in a private network) that the next
+ downstream element that will be in the path of subsequent requests
+ supports that transport.
+
+ The preceding seems to confuse implementors, resulting in proxies
+ that insert a single Record-Route without a transport URI parameter,
+ resulting in the problems described in this section.
+
+6.1. UA Implementation Problems and Recommendations
+
+ Consider the following scenario: a SIP proxy, doing TCP to UDP
+ transport protocol switching.
+
+ In this example, proxy P1, responsible for the domain
+ biloxy.example.com, receives a request from Alice UA1, which uses
+ TCP. It proxies this request to Bob UA2, which registered with a
+ Contact specifying UDP as transport protocol. Thus, P1 receives an
+ initial request from Alice over TCP and forwards it to Bob over UDP.
+ For subsequent requests, it is expected that TCP could continue to be
+ used between Alice and P1, and UDP between P1 and Bob, but this can
+ not happen if a numeric IP address is used and no transport parameter
+ is set on Record-Route URI. This happens because of procedures
+ described in [RFC3263]. Some mandatory SIP headers have been omitted
+ to ease readability.
+
+
+
+
+
+
+
+Froment, et al. Standards Track [Page 10]
+
+RFC 5658 SIP Record-Route Fix October 2009
+
+
+ Alice UA1 ===== TCP ===== Proxy P1 ===== UDP ===== Bob UA2
+ | | |
+ | F1 INVITE | |
+ |----------------------->| F2 INVITE |
+ | |------------------------>|
+ | 100 Trying | |
+ |<-----------------------| |
+ | | F3 200 OK |
+ | F4 200 OK |<------------------------|
+ |<-----------------------| |
+ | | |
+ | F5 ACK | |
+ |---(sent over UDP) X--->| ACK |
+ | |------------------------>|
+ | | |
+ | | F6 BYE |
+ | BYE |<------------------------|
+ |<-----------------------| |
+
+ Figure 4: TCP to UDP Transport Protocol
+ Switching Issue Illustration
+
+ F1 INVITE UA1 -> P1 (192.0.2.1/tcp)
+
+ INVITE sip:bob@biloxi.example.com SIP/2.0
+ Route: <sip:192.0.2.1;lr;transport=tcp>
+ From: Alice <sip:alice@atlanta.example.com>;tag=1234
+ To: Bob <sip:bob@biloxi.example.com>
+ Contact: <sip:alice@ua1.atlanta.example.com;transport=tcp>
+
+ F2 INVITE P1 -> UA2 (ua2.biloxi.example.com/udp)
+
+ INVITE sip:bob@ua2.biloxi.example.com;transport=udp SIP/2.0
+ Record-Route: <sip:192.0.2.1;lr> (NO transport param)
+ From: Alice <sip:alice@atlanta.example.com>;tag=1234
+ To: Bob <sip:bob@biloxi.example.com>
+ Contact: <sip:alice@ua1.atlanta.example.com;transport=tcp>
+
+ Dialog State at UA2:
+ Local URI = sip:bob@biloxi.example.com
+ Remote URI = sip:alice@atlanta.example.com
+ Remote target = sip:alice@ua1.atlanta.example.com;transport=tcp
+ Route Set = sip:192.0.2.1;lr
+
+
+
+
+
+
+
+
+Froment, et al. Standards Track [Page 11]
+
+RFC 5658 SIP Record-Route Fix October 2009
+
+
+ F3 200 OK UA2 -> P1 (192.0.2.1/udp)
+
+ SIP/2.0 200 OK
+ Record-Route: <sip:192.0.2.1;lr>
+ From: Alice <sip:alice@atlanta.example.com>;tag=1234
+ To: Bob <sip:bob@biloxi.example.com>;tag=4567
+ Contact: <sip:bob@ua2.biloxi.example.com>
+
+ F4 200 OK P1 -> UA1 (ua1.atlanta.example.com/tcp)
+
+ SIP/2.0 200 OK
+ Record-Route: <sip:192.0.2.1;lr>
+ From: Alice <sip:alice@atlanta.example.com>;tag=1234
+ To: Bob <sip:bob@biloxi.example.com>;tag=4567
+ Contact: <sip:bob@ua2.biloxi.example.com>
+
+ Dialog State at UA1:
+ Local URI = sip:alice@atlanta.example.com
+ Remote URI = sip:bob@biloxi.example.com
+ Remote target = sip:bob@ua2.biloxi.example.com
+ Route Set = sip:192.0.2.1;lr
+
+
+ F5 ACK UA1 -> P1 (192.0.2.1/udp)
+
+ ACK sip:bob@ua2.biloxi.example.com SIP/2.0
+ Route: <sip:192.0.2.1;lr>
+ From: Alice <sip:alice@atlanta.example.com>;tag=1234
+ To: Bob <sip:bob@biloxi.example.com>;tag=4567
+
+ F6 BYE UA2 -> P1 (192.0.2.1/udp)
+
+ BYE sip:alice@ua1.atlanta.example.com;transport=tcp SIP/2.0
+ Route: <sip:192.0.2.1;lr>
+ From: Bob <sip:bob@biloxi.example.com>;tag=4567
+ To: Alice <sip:alice@atlanta.example.com>;tag=1234
+
+ Figure 5: TCP to UDP Transport Protocol
+ Switching Issue Description
+
+ Since the proxy P1 does not insert any transport parameter in the
+ Record-Route URI, subsequent in-dialog requests of UA1, like the ACK
+ sent in F5, will be sent according to the behavior specified in
+ Section 12.2 (requests within a Dialog) of [RFC3261]. That means
+ that the routeset is used, and then, applying [RFC3263], the Route
+ "sip:192.0.2.1" will resolve to a UDP transport by default (since no
+ transport parameter is present here), and no Naming Authority Pointer
+ (NAPTR) request will be performed since this is a numeric IP address.
+
+
+
+Froment, et al. Standards Track [Page 12]
+
+RFC 5658 SIP Record-Route Fix October 2009
+
+
+ In general, the interoperability problems arise when UA1 is trying to
+ send the ACK: it is not ready to change its transport protocol for a
+ mid-dialog request and just fails to do so, requiring the proxy
+ implementor to insert the transport protocol in the Record-Route URI.
+
+ What happens if the proxy had Record-Routed its logical name
+ (biloxi.example.com)? Since Bob is to be contacted over UDP,
+ protocol switching will be avoided only if the resulting transport
+ protocol of [RFC3263] procedures is UDP. For any other resulting
+ transport protocol, the transport protocol switching issue described
+ above will occur. Also, if one of the UAs sends an initial request
+ using a different transport than the one retrieved from DNS, this
+ scenario would be problematic.
+
+ In practice, there are multiple situations where UA implementations
+ don't use logical names and NAPTR records when sending an initial
+ request to a proxy. This happens, for instance, when:
+
+ 1) UAs offer the ability to "choose" the transport to be used for
+ initial requests, even if they support [RFC3263]. This is a
+ frequent UA functionality that is justified by the following use
+ cases:
+
+ - when it is not possible to change the DNS server configuration
+ and the implementation doesn't support all the transport
+ protocols that could be configured by default in DNS (e.g.,
+ TLS).
+
+ - when the end-user wants to choose his transport protocol for
+ whatever reason, e.g., needing to force TCP, avoiding
+ UDP/congestion, retransmitting, or fragmenting, etc.
+
+ This ability to force the transport protocol in UAs for initial
+ requests SHOULD be avoided: selecting the transport protocol in the
+ configuration of an outbound proxy means that [RFC3263] procedure is
+ bypassed for initial requests. As a consequence, if the proxy
+ Record-Routed with no transport parameter as is recommended in
+ [RFC3261], the UA will be forced to use the [RFC3263]-preferred
+ transport for subsequent requests anyway, which leads to the
+ problematic scenario described in Figure 4.
+
+ 2) UAs decide to always keep the same transport for a given dialog.
+ This choice is erratic, since if the proxy is not Record-Routing,
+ the callee MAY receive the subsequent request through a transport
+ that is not the one put in its Contact. If a UA really wants to
+ avoid transport protocol switching between the initial and
+ subsequent request, it SHOULD rely on DNS records for that; thus,
+
+
+
+
+Froment, et al. Standards Track [Page 13]
+
+RFC 5658 SIP Record-Route Fix October 2009
+
+
+ it SHOULD avoid configuring statically the outbound proxy with a
+ numeric IP address. A logical name, with no transport parameter,
+ SHOULD be used instead.
+
+ 3) UAs don't support [RFC3263] at all, or don't have any DNS server
+ available. In that case, as illustrated previously, forcing UA1
+ to switch from TCP to UDP between initial request and subsequent
+ request(s) is clearly not the desired default behavior, and it
+ typically leads to interoperability problems. UA implementations
+ SHOULD then be ready to change the transport protocol between
+ initial and subsequent requests. In theory, any UA or proxy using
+ UDP must also be prepared to use TCP for requests that exceed the
+ size limit of path MTU, as described in Section 18.1.1 of
+ [RFC3261].
+
+6.2. Proxy Implementation Problems and Recommendations
+
+ In order to prevent UA implementation problems, and to maintain a
+ reasonable level of interoperability, the situation can be improved
+ on the proxy side. Thus, if the transport protocol changed between
+ its incoming and outgoing sides, the proxy SHOULD use the double
+ Record-Route technique and SHOULD add a transport parameter to each
+ of the Record-Route URIs it inserts. When TLS is used on the
+ transport on either side of the proxy, the URI placed in the Record-
+ Route header field MUST encode a next-hop that will be reached using
+ TLS. There are two ways for this to work. The first way is for the
+ URI placed in the Record-Route to be a SIPS URI. The second is for
+ the URI placed in the Record-Route to be constructed such that
+ application of [RFC3263] resolution procedures to that URI results in
+ TLS being selected. Proxies compliant with this specification MUST
+ NOT use a "transport=tls" parameter on the URI placed in the Record-
+ Route because the "transport=tls" usage was deprecated by [RFC3261].
+ Record-Route rewriting MAY also be used. However, the recommendation
+ to put a transport protocol parameter on Record-Route URI does not
+ apply when the proxy has changed the transport protocol due to the
+ size of UDP requests as per Section 18.1.1 of [RFC3261]. As an
+ illustration of the previous example, it means one of the following
+ processing will be performed:
+
+ - Double Record-Routing: the proxy inserts two Record-Route headers
+ into the SIP request. The first one is set, in this example, to
+ Record-Route: <sip:192.0.2.1;lr;transport=tcp>, the second one is
+ set to Record-Route: <sip:192.0.2.1;lr> with no transport, or with
+ transport=udp, which basically means the same thing.
+
+ - Record-Route rewriting on responses: in the INVITE request sent in
+ F2, the proxy puts the outgoing transport protocol in the transport
+ parameter of Record-Route URI. Doing so, UA2 will correctly send
+
+
+
+Froment, et al. Standards Track [Page 14]
+
+RFC 5658 SIP Record-Route Fix October 2009
+
+
+ its BYE request in F6 using the same transport protocol as previous
+ messages of the same dialog. The proxy rewrites the Record-Route
+ when processing the 200 OK response, changing the transport
+ parameter "on the fly" to "transport=tcp", so that the Route set
+ will appear to be <sip:192.0.2.1;lr;transport=tcp> for UA1 and
+ <sip:192.0.2.1;lr;transport=udp> for UA2.
+
+ It is a common practice in proxy implementations to support double
+ Record-Route AND to insert the transport parameter in the Record-
+ Route URI. This practice is acceptable as long as all SIP elements
+ that may be in the path of subsequent requests support that
+ transport. This restriction needs an explanation. Let's imagine you
+ have two proxies, P1 at "p1.biloxi.example.com" and P2 on the path of
+ an initial request. P1 is Record-Routing and changes the transport
+ from UDP to Stream Control Transmission Protocol (SCTP) because the
+ P2 URI resolves to SCTP applying [RFC3263]. Consequently, the proxy
+ P1 inserts two Record-Route headers:
+
+ Record-Route: <sip:p1.biloxi.example.com;transport=udp> and
+
+ Record-Route: <sip:p1.biloxi.example.com;transport=sctp>.
+
+ The problem arises if P2 is not Record-Routing, because the SIP
+ element downstream of P2 will be asked to reach P1 using SCTP for any
+ subsequent, in-dialog request from the callee, and this downstream
+ SIP element may not support that transport.
+
+ In order to handle this situation, this document recommends that a
+ proxy SHOULD apply the double Record-Routing technique as soon as it
+ changes the transport protocol between its incoming and outgoing
+ sides. If proxy P2 in the example above would follow this
+ recommendation, it would perform double Record-Routing and the
+ downstream element would not be forced to send requests over a
+ transport it does not support.
+
+ By extension, a proxy SHOULD also insert a Record-Route header for
+ any multi-homed situation (as the ones described in this document:
+ scheme changes, sigcomp, IPv4/IPv6, transport changes, etc.) that may
+ impact the processing of proxies being on the path of subsequent
+ requests.
+
+7. Conclusion
+
+ As a conclusion of this document, it is to notice that:
+
+ - Record-Route rewriting is presented as a technique that MAY be
+ used, with the drawbacks outlined in Section 4.
+
+
+
+
+Froment, et al. Standards Track [Page 15]
+
+RFC 5658 SIP Record-Route Fix October 2009
+
+
+ - Double Record-Routing is presented as the technique that SHOULD be
+ used, and is documented in Section 5.
+
+ - Record-Route header interoperability problems on transport protocol
+ switching scenarios have been outlined and described in Section 6.
+ This last section gives some recommendations to UA and proxy
+ implementations to improve the situation. Proxies SHOULD use
+ double Record-Routing for any multi-homed situation that MAY impact
+ the further processing, and they SHOULD put transport protocol
+ parameters on Record-Route URIs in some circumstances. UAs SHOULD
+ NOT offer options to overwrite the transport for initial requests.
+ Further, UAs SHOULD rely on DNS to express their desired transport
+ and SHOULD avoid IP addresses with transport parameters in this
+ case. Finally, UAs SHOULD be ready to switch transports between
+ the initial request and further in-dialog messages.
+
+8. Security Considerations
+
+ The recommendations in this document describe a way to use the
+ existing protocol specified in RFC 3261 rather than introducing any
+ new protocol mechanism. As such, they do not introduce any new
+ security concerns, but additional consideration of already existing
+ concerns is warranted. In particular, when a message is transiting
+ two interfaces, the double Record-Route technique will carry
+ information about both interfaces to each of the involved endpoints
+ (and any intermediaries between this proxy and those endpoints),
+ where the rewriting technique would only expose information about the
+ interface closest to each given endpoint. If issues such as topology
+ hiding or privacy (as described in [RFC3323]) are a concern, the URI
+ values placed in the Record-Route for each interface should be
+ carefully constructed to avoid exposing more information than was
+ intended.
+
+9. Acknowledgments
+
+ Thank you to Dean Willis, Vijay K. Gurbani, Joel Repiquet, Robert
+ Sparks, Jonathan Rosenberg, Cullen Jennings, Juha Heinanen, Paul
+ Kyzivat, Nils Ohlmeier, Tim Polk, Francois Audet, Adrian Farrel,
+ Ralph Droms, Tom Batsele, Yannick Bourget, Keith Drage, and John
+ Elwell for their reviews and comments.
+
+
+
+
+
+
+
+
+
+
+
+Froment, et al. Standards Track [Page 16]
+
+RFC 5658 SIP Record-Route Fix October 2009
+
+
+10. References
+
+10.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+ A., Peterson, J., Sparks, R., Handley, M., and E.
+ Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+ June 2002.
+
+ [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
+ Protocol (SIP): Locating SIP Servers", RFC 3263, June
+ 2002.
+
+ [RFC3323] Peterson, J., "A Privacy Mechanism for the Session
+ Initiation Protocol (SIP)", RFC 3323, November 2002.
+
+ [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session
+ Initiation Protocol (SIP)", RFC 5630, October 2009.
+
+10.2. Informative References
+
+ [BUG664] Sparks, RS., "Bug 664: Double record routing,
+ http://bugs.sipit.net/show_bug.cgi?id=664", October 2002.
+
+ [RFC3486] Camarillo, G., "Compressing the Session Initiation
+ Protocol (SIP)", RFC 3486, February 2003.
+
+ [RFC3608] Willis, D. and B. Hoeneisen, "Session Initiation Protocol
+ (SIP) Extension Header Field for Service Route Discovery
+ During Registration", RFC 3608, October 2003.
+
+ [V6Tran] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6
+ Transition in the Session Initiation Protocol (SIP)", Work
+ in Progress, August 2009.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Froment, et al. Standards Track [Page 17]
+
+RFC 5658 SIP Record-Route Fix October 2009
+
+
+Authors' Addresses
+
+ Thomas Froment
+ Tech-invite
+
+ EMail: thomas.froment@tech-invite.com
+
+
+ Christophe Lebel
+ Alcatel-Lucent
+ Lieu dit Le Mail
+ Orvault 44708
+ France
+
+ EMail: christophe.lebel@alcatel-lucent.com
+
+
+ Ben Bonnaerens
+ Alcatel-Lucent
+ Copernicuslaan 50
+ Antwerpen 2018
+ Belgium
+
+ EMail: ben.bonnaerens@alcatel-lucent.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Froment, et al. Standards Track [Page 18]
+