Network Working Group T. Froment
Internet-Draft C. Lebel
Intended status: Best Current Alcatel-Lucent
Practice November 9, 2007
Expires: May 12, 2008
Addressing Record-Route issues in the Session Initiation Protocol (SIP)
draft-ietf-sip-record-route-fix-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 12, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Froment & Lebel Expires May 12, 2008 [Page 1]
Internet-Draft SIP Record-Route fix November 2007
Abstract
A typical function of a Session Initiation Protocol (SIP) Proxy is to
set a Record-Route header on initial requests in order to make
subsequent requests pass through it. This header contains a SIP
Uniform Resource Identifier (URI) indicating where and how the
subsequent requests should be sent to reach the proxy. Like any SIP
URI, it can contain sip or sips schemes, IPV4 or IPV6 addresses, and
URI parameters that could influence the routing like different
transport parameters (UDP, TCP, SCTP...), 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, sip to sips or IPV4 to IPV6
scenarios...), the question arises on what should be put in Record-
Route header(s). It is just not possible to make one header having
the characteristics of both sides 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 RFC3261 text, which only
describes Record-Route rewriting solution.
Froment & Lebel Expires May 12, 2008 [Page 2]
Internet-Draft SIP Record-Route fix November 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Background: multi-homed proxies . . . . . . . . . . . . . 7
3.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Record-Route rewriting . . . . . . . . . . . . . . . . . . . . 9
5. Double Record-Routing . . . . . . . . . . . . . . . . . . . . 10
6. Usage of transport parameter . . . . . . . . . . . . . . . . . 14
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 26
Froment & Lebel Expires May 12, 2008 [Page 3]
Internet-Draft SIP Record-Route fix November 2007
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), sip to sips... 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 provide 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 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".
- ID [I-D.ietf-sipping-v6-transition], section 3.1.1, mandates
double Record-Routing for multi-homed proxies doing IPV4/IPV6
transitions, when the proxy inserts IP addresses.
- ID [I-D.ietf-sip-sips], recommends to apply the double
Record-Routing technique when a proxy has to change the scheme
from sip to sips; again, the scope is limited to this use case.
The observed interoperability problems can be explained by the fact
that, despite these multiple documents, RFC3261 description has not
been changed, and many implementors don't support extensions like
Service-Route ([RFC3608]) or SIGCOMP([RFC3486]). Indeed, why doing
so just for implementing a multi-home proxy or transport protocol
switching basic function?
By the way, this document also aims to clarify identified bugs
referenced in [BUG664], [BUG734] and [BUG735]. In particular, it
takes into account [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".
Froment & Lebel Expires May 12, 2008 [Page 4]
Internet-Draft SIP Record-Route fix November 2007
This document is also following recommendations of
[I-D.drage-sip-essential-correction], which describes the process for
handling essential corrections to the Session Initiation Protocol.
Froment & Lebel Expires May 12, 2008 [Page 5]
Internet-Draft SIP Record-Route fix November 2007
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 & Lebel Expires May 12, 2008 [Page 6]
Internet-Draft SIP Record-Route fix November 2007
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 model is shown here:
+-----+
| UA1 |
+--+--+
| .2
10.1.1.0/25 |
----------------+---+-...
|
| .1
+-+-+
| P |
+-+-+
| .1
| 192.0.2.1/24
...---+------+------------------
|
| .2
+--+--+
| UA2 |
+--+--+
UA1 has one interface with IP address 10.1.1.2.
P has two interfaces and two addresses:
-- 10.1.1.1
-- 192.0.2.1
And UA2 has one interface with address, 192.0.2.2. In other words,
there is no IP level route between UA1 and UA2; no ping; no
traceroute. They live in entirely different networks. But they can
still exchange SIP messages, because P is a SIP Proxy. This works in
SIP because P can "record-route".
Froment & Lebel Expires May 12, 2008 [Page 7]
Internet-Draft SIP Record-Route fix November 2007
3.2. Problems
Handling of Record-Route header in SIP Proxies is specified by
following sections of [RFC3261]:
On 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 at all that the proxy
SHOULD put the transport parameter of its outgoing interface in
order to rewrite it later in responses: this can not be optional.
Then, this section speaks about record-route requirements when
transiting from sips to non-sips. It's not clear that the section
doesn't apply to TLS to non-TLS transitions where SIPS is not
involved (see [BUG734]).
On 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 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". Indeed, [RFC3261] suggests rewriting the Record-Route
header in responses, and mandates it if the request indicated
"SIP:". The current text indicates that the Record-Route value
MUST be modified to contain a SIPS URI when routing a response
from non-TLS to TLS transports. This makes sense only if the
request indicated SIPS. Hop-by-hop TLS needs to be covered
separately, see [BUG735]).
This list enlights the utility of rewriting and double Record-Routing
techniques which apply for any multi-homed proxy use case, whenever
the proxy changes its IP address, the transport parameter or the URI
scheme between incoming and outgoing interfaces. This is why, these
techniques are described, compared and discussed in sections 4 and 5;
the specific question to put or not the transport parameter on
Record-Route is then discussed in Section 6.
Froment & Lebel Expires May 12, 2008 [Page 8]
Internet-Draft SIP Record-Route fix November 2007
4. Record-Route rewriting
As already outlined in some IETF mailing list discussions: Record-
Route rewriting in responses is controversial. Actually, it has
often been noticed that letting [RFC3261] with the Record-Route
rewriting as the only technique described in core specification is
dangerous, due to the fact that rewriting has some heavy drawbacks.
Indeed, 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
it has two serious implications:
1) 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 can not be supported by the protocol. The openness and
the end-to-end principles are broken (!)...
2) Proxy must implement special "multi-homed" stateful logic. On
the request phase, it goes through output interface calculation
and writes the output interface into the route. It must then
inspect all responses, grep for an input interface, and
selectively edit them to reference the correct output interface:
this is a CPU drag.
That's why, this document RECOMMENDS to not use this technique.
However, it SHOULD be clarified that its scope is wider than just the
"sip to sips" use case, and SHOULD be extended to any transport
protocol switching, or "multi-homed" situations:
Thus, on the request processing side: item 4 of section 16.6 of
[RFC3261], it SHOULD be noticed that the URI MAY contain the
transport parameter or the outgoing interface in case of a multi-
homed proxy, and that it would trigger the Record-Route rewriting
when processing responses.
On the response processing side: step 8 of section 16.7, it SHOULD
be noticed that the mechanism also applies to transport protocol
switching or any multi-homed scenarios, and not only to scheme
changes.
Froment & Lebel Expires May 12, 2008 [Page 9]
Internet-Draft SIP Record-Route fix November 2007
5. Double Record-Routing
Important drawbacks of rewriting technique probably explain why
double Record-Routing solution has consequently always been
recommended in SIP extensions like [RFC3486] or [RFC3608]. That's
also why this document formally RECOMMENDS to use it as an
alternative to rewriting in [RFC3261].
This technique has many benefits, and is completely backwards
compatible with [RFC3261]. It consists in putting as the first
value, the Route of receiving interface, including schemes and/or URI
parameters, and, as second value, the Route of the sending interface.
When processing the response, no modification of the recorded route
is required.
When double Record-Routing, the proxy will have to handle the
subsequent in-dialog request(s) as a spiral, and consequently devote
some space to maintaining a transaction. In order to avoid a spiral,
the proxy has to be smart and scan an extra route 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, and it means that the appropriate section of[RFC3261] is
impacted:
Scanning two routes instead of one implies that the proxy behaviour
described in section 16.4. "Route Information Preprocessing" of
[RFC3261] MAY remove these TWO routes instead of one. This section
SHOULD then be modified by adding to the current text "If the first
value in the Route header field indicates this proxy, the proxy MUST
remove that value from the request" the following statement "If the
proxy used double Record-Routing technique for this dialog, the same
treatment MAY be applied a second time, and then remove the second
value of Route header".
Generally speaking, the time complexity will be less in double
Record-Routing since on the response, the proxy does not have to do
any re-writes (and thus, no searching).
The following example is an extension of the example given
in[I-D.ietf-sipping-v6-transition], it illustrates a basic call flow
when doing double Record-Routing in a multi-homed IPV4 to IPV6 proxy,
enlightening the Dialog State on each UA. In this example, proxy P1,
responsible for the domain biloxy.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.1 and on the IPv6
interface, it is configured with an address of 2001:db8::1.
Froment & Lebel Expires May 12, 2008 [Page 10]
Internet-Draft SIP Record-Route fix November 2007
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 |<-------------------|
|<-------------------| |
| F9 200 OK | |
|------------------->| F10 200 OK |
| |------------------->|
IPV4 to IPV6 multi-homed proxy illustration
UA1 P1 UA2
F1 INVITE UA1 -> P1
INVITE sip:bob@biloxi.com SIP/2.0
Route: <sip:192.0.2.254:5060;lr>
From: Alice <sip:alice@atlanta.com>;tag=1234
To: Bob <sip:bob@biloxi.com>
Contact: <sip:alice@192.0.2.1>
F2 INVITE P1 -> UA2
INVITE sip:bob@biloxi.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.com>;tag=1234
To: Bob <sip:bob@biloxi.com>
Contact: <sip:alice@192.0.2.1>
Dialog State at UA2:
Local URI = sip:bob@biloxi.com
Froment & Lebel Expires May 12, 2008 [Page 11]
Internet-Draft SIP Record-Route fix November 2007
Remote URI = sip:alice@atlanta.com
Remote target = sip:alice@192.0.2.1
Route Set = sip:2001:db8::1;lr
sip:192.0.2.254:5060:lr
F3 200 OK UA2 -> P1
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.com>;tag=1234
To: Bob <sip:bob@biloxi.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.com>;tag=1234
To: Bob <sip:bob@biloxi.com>;tag=4567
Contact: <sip:bob@2001:db8::33>
Dialog State at UA1:
Local URI = sip:alice@atlanta.com
Remote URI = sip:bob@biloxi.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
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.com>;tag=1234
To: Bob <sip:bob@biloxi.com>;tag=4567
F6 ACK P1 -> UA2
ACK sip:bob@2001:db8::33 SIP/2.0
From: Alice <sip:alice@atlanta.com>;tag=1234
To: Bob <sip:bob@biloxi.com>;tag=4567
(both routes have been removed by the proxy)
F7 BYE UA2 -> P1
BYE sip:alice@192.0.2.1 SIP/2.0
Froment & Lebel Expires May 12, 2008 [Page 12]
Internet-Draft SIP Record-Route fix November 2007
Route: <sip:2001:db8::1;lr>
Route: <sip:192.0.2.254:5060:lr>
From: Bob <sip:bob@biloxi.com>;tag=4567
To: Alice <sip:alice@atlanta.com>;tag=1234
F8 BYE P1 -> UA1
BYE sip:alice@192.0.2.1 SIP/2.0
From: Bob <sip:bob@biloxi.com>;tag=4567
To: Alice <sip:alice@atlanta.com>;tag=1234
F9 SIP/2.0 200 OK UA1 -> P1
From: Bob <sip:bob@biloxi.com>;tag=4567
To: Alice <sip:alice@atlanta.com>;tag=1234
F10 SIP/2.0 200 OK P1 -> UA2
From: Bob <sip:bob@biloxi.com>;tag=4567
To: Alice <sip:alice@atlanta.com>;tag=1234
Figure 3: Multi-homed IPV4 to IPV6 double Record-Routing illustration
Froment & Lebel Expires May 12, 2008 [Page 13]
Internet-Draft SIP Record-Route fix November 2007
6. Usage of transport parameter
Let's consider the following scenario: a SIP proxy, doing TCP to UDP
transport-switching. In some circumstances interoperability problems
occur because it is not clear if transport parameter SHOULD be put on
URI of Record-Route header or not; it was identified as a frequent
problem in past SIPIT events. The statement "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", is
often considered as confusing: applying this statement, a proxy just
puts one Record-Route, without any transport parameters, which
generally leads to the problem illustrated below. In this example,
proxy P1, responsible for the domain biloxy.com, receives a request
from Alice UA which uses TCP. It proxies this request to Bob UA
which registered with a Contact specifying UDP as transport protocol.
P1 thus receives an initial request from Alice in TCP and forwards it
in UDP to Bob. For subsequent requests, it is expected that TCP could
continue to be used between Alice and P1, and UDP between P1 and Bob,
but it can not happen if numeric IP address is used and no transport
parameter is set on Record-Route URI.
Alice ===== TCP ===== Proxy ===== UDP ===== Bob
| | |
| F1 INVITE | |
|------------------->| F2 INVITE |
| |------------------->|
| 100 Trying | |
|<-------------------| |
| | F3 200 OK |
| F4 200 OK |<-------------------|
|<-------------------| |
| | |
| F5 ACK | |
|--(sent in UDP) X-> | ACK |
| |------------------->|
| | |
| | F6 BYE |
| BYE |<-------------------|
|<-------------------| |
Simplified TCP to UDP proxy scenario description
UA1 P1 UA2
Froment & Lebel Expires May 12, 2008 [Page 14]
Internet-Draft SIP Record-Route fix November 2007
F1 INVITE UA1 -> P1
INVITE sip:bob@biloxi.com SIP/2.0
Route: <sip:192.0.2.1;lr;transport=tcp>
From: Alice <sip:alice@atlanta.com>;tag=1234
To: Bob <sip:bob@biloxi.com>
Contact: <sip:alice@ua1.atlanta.com;transport=tcp>
F2 INVITE P1 -> UA2
INVITE sip:bob@biloxi.com SIP/2.0
Record-Route: <sip:192.0.2.1;lr> (NO transport param)
From: Alice <sip:alice@atlanta.com>;tag=1234
To: Bob <sip:bob@biloxi.com>
Contact: <sip:alice@ua1.atlanta.com;transport=tcp>
Dialog State at UA2:
Local URI = sip:bob@biloxi.com
Remote URI = sip:alice@atlanta.com
Remote target = sip:alice@ua1.atlanta.com;transport=tcp
Route Set = sip:192.0.2.1;lr
F3 200 OK UA2 -> P1
SIP/2.0 200 OK
Record-Route: <sip:192.0.2.1;lr>
From: Alice <sip:alice@atlanta.com>;tag=1234
To: Bob <sip:bob@biloxi.com>;tag=4567
Contact: <sip:bob@ua2.biloxi.com>
F4 200 OK P1 -> UA1
SIP/2.0 200 OK
Record-Route: <sip:192.0.2.1;lr>
From: Alice <sip:alice@atlanta.com>;tag=1234
To: Bob <sip:bob@biloxi.com>;tag=4567
Contact: <sip:bob@ua2.biloxi.com>
Dialog State at UA1:
Local URI = sip:alice@atlanta.com
Remote URI = sip:bob@biloxi.com
Remote target = sip:bob@ua2.biloxi.com
Route Set = sip:192.0.2.1;lr
F5 ACK UA1 -> P1
ACK sip:bob@ua2.biloxi.com SIP/2.0
Froment & Lebel Expires May 12, 2008 [Page 15]
Internet-Draft SIP Record-Route fix November 2007
Route: <sip:192.0.2.1;lr>
From: Alice <sip:alice@atlanta.com>;tag=1234
To: Bob <sip:bob@biloxi.com>;tag=4567
F6 BYE UA2 -> P1
BYE sip:alice@ua1.atlanta.com;transport=tcp SIP/2.0
Route: <sip:192.0.2.1;lr>
From: Bob <sip:bob@biloxi.com>;tag=4567
To: Alice <sip:alice@atlanta.com>;tag=1234
Figure 5: TCP to UDP problem illustration
Since P1 Proxy does not put any transport parameter on Record-Route,
subsequent requests of UA1, like the ACK sent in F5, will be sent
according to the behaviour specified in section 12.2 (requests within
a Dialog) of RFC 3261, that means that the Route set 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 available
here), and no NAPTR request will be performed since this is a numeric
IP Address. Even if the proxy had record-routed its logical name
(e.g. p1.example.com), if UA1 and UA2 use the same DNS server, NAPTR
request would resolve to the same transport on both sides. That
means, even if we assume that UAs support [RFC3263], if one of the UA
sends an initial request using a different transport than the one
configured in DNS, this scenario is problematic. In practice, there
are multiple situations where UAs don't use logical names and NAPTR
records when sending an initial request to a proxy:
- Most of the UAs offer the ability to "force" the transport to be
used for initial requests, even if they support [RFC3263]: this is
because in some circumstances, people just want to avoid using, for
instance, UDP (trying to avoid congestion, retransmissions or
fragmentation), or just because they simply don't support one of the
transport. This usage SHOULD be avoided, because forcing the
transport parameter in the configuration of an outbound proxy means
that NAPTR records won't be used for initial requests, but if the
proxy Record-Routed with no transport parameter as recommended in
[RFC3261], then, the UA will anyway be forced to use the NAPTR-
preferred transport for subsequent requests.
- In any case, a UA implementation SHOULD be ready to change the
transport between initial and subsequent requests.
- Knowing this problem, some UA implementations sometimes decide to
always keep the same transport for a given Dialog, but 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
Froment & Lebel Expires May 12, 2008 [Page 16]
Internet-Draft SIP Record-Route fix November 2007
one put in its Contact. If a UA wants to avoid transport protocol
switching between initial and subsequent request, it SHOULD rely on
DNS records for that, and thus it SHOULD avoid configuring statically
the outbound proxy with a numeric IP address: a logical name, with no
transport parameter SHOULD be used instead.
- Some 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 behaviour, and it
typically leads to interoperability problems. In that case, if the
proxy record-routes a numeric IP Address and transport protocol
switching occurs, something needs to be done.
In order to workaround this problem, and to maintain a reasonnable
level of interoperability, solutions are generally provided on proxy
side. The proxy MAY then put a transport parameter on Record-Route
URIs, and use either rewriting or double record-route techniques if
transport protocol changed between its incoming and outgoing sides.
As an illustration on previous example it means one of the following
processing will be performed:
- Record-Route rewriting on responses: put the transport parameter on
the Record-Route of INVITE request sent in F2, so that UA2 will
correctly send its BYE request in F6 using the same transport as
previous messages of the same dialog, and make the Proxy rewrite the
Record-Route when processing the 200 OK response, changing "on the
fly" the transport parameter 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.
- Double Record-Routing: the proxy puts two Record-Route headers.
The first one is set, in this example, to Record-Route: <sip:
192.0.2.1;lr;transport=TCP>, the second one to Record-Route: <sip:
192.0.2.1;lr> with no transport, or with transport=UDP, which means
basically the same thing.
This is a common practice in proxy implementations to support double
Record-Route AND put the transport parameters. 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" and "P2" on
the path of an initial request. P1 is record-route and changes the
transport from UDP to SCTP because P2 URI resolves to SCTP transport
applying [RFC3263], and consequently decides to put two Record-Route,
one with P1;transport=UDP, another one with P1;transport=SCTP. The
problem arises if P2 is not record-route, because the next SIP
element after P2 will be asked to reach P1 using SCTP transport for
Froment & Lebel Expires May 12, 2008 [Page 17]
Internet-Draft SIP Record-Route fix November 2007
any subsequent request from callee, and this SIP element MAY NOT
support that transport. In order to handle this situation, this
document would recommend that a proxy SHOULD put a Record-Route
header as soon as it changes the transport protocol parameter between
its incoming and outgoing sides.
By extension, a proxy SHOULD also put a Record-Route header for any
multi-homed situation (as the ones described in this document;
sigcomp, IPv4/IPv6...) that MAY impact the processing of proxies
being on the path of subsequent requests. It implies to modify
section 16.6, item 4, S.8 of [RFC3261], replacing the following
statement: "The URI this proxy provides will be used by some other
element to make a routing decision. This proxy, in general, has no
way of knowing the capabilities of that element, so it must restrict
itself to the mandatory elements of a SIP implementation: SIP URIs
and either the TCP or UDP transports" by a more general statement
like: "The URI this proxy provides will be used by some other element
to make a routing decision. This proxy, in general, has no way of
knowing the capabilities of that element. So if any change related
to the routing capabilities of elements being on the path of
subsequent requests occurs between incoming and outgoing side of a
proxy (change of transport protocol, scheme, IP address version,...),
the proxy SHOULD put a Record-Route header".
Froment & Lebel Expires May 12, 2008 [Page 18]
Internet-Draft SIP Record-Route fix November 2007
7. Conclusion
As a conclusion of this document, it SHOULD be noticed that:
- Description of Record-Route rewriting is clarified as
recommended in section 4 of this document. It impacts request
processing in SIP proxy, item 4 of section 16.6 of [RFC3261], and
response processing at step 8 of section 16.7. In particular, it
SHOULD be noticed that this mechanism also applies to transport
protocol switching or any multi-homed scenarios, and not only to
scheme changes.
- Given the outlined drawbacks of rewriting, this document let
rewriting as a technique that MAY be used, and double record-
routing as the technique that SHOULD be used. Sections 16.4, of
[RFC3261] on "Route Information Preprocessing" SHOULD then be read
as recommended in section 5.
- Clarifications on transport protocol switching scenarios, as
they are described in section 6 of this document are important in
order to avoid interoperability problems. It gives some
recommendations to UA implementations, and substantially modifies
proxy specification in sections 16.6, item 4 and 16.7, step 8 of
[RFC3261].
Froment & Lebel Expires May 12, 2008 [Page 19]
Internet-Draft SIP Record-Route fix November 2007
8. IANA Considerations
This document does not require any actions by IANA.
Froment & Lebel Expires May 12, 2008 [Page 20]
Internet-Draft SIP Record-Route fix November 2007
9. Security Considerations
The double Record-Routing technique reveals some level of network
topology and proxy server capabilities: IPv4 and IPv6 support, SCTP
support, sigcomp support, etc. to a malicious attacker. This is a
bit more than the normal IP address, naming scheme information that
is usually part and parcel of every SIP request sent out in the
clear. It MAY have an impact on services involving topology hidding
or privacy, as specified in [RFC3323].
Froment & Lebel Expires May 12, 2008 [Page 21]
Internet-Draft SIP Record-Route fix November 2007
10. Acknowledgments
Dean Willis who contributed, through the mailing lists, to most of
the problem statement elements.
Vijay K. Gurbani who provided important references and substantial
modifications, also raising security considerations.
Robert Sparks and Juha Heinanen for mailing list contributions.
Tom Batsele who helped to clarify the transport-switching issues.
Joel Repiquet for his review.
Ben Bonnaerens for a very attentive review and good suggestions.
Froment & Lebel Expires May 12, 2008 [Page 22]
Internet-Draft SIP Record-Route fix November 2007
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
11.2. Informative References
[BUG664] Sparks, RS., "Bug 664: Double record routing,
http://bugs.sipit.net/show_bug.cgi?id=664", October 2002.
[BUG734] Sparks, RS., "Bug 734: Record-route manipulation rules for
requests wrt SIPS vs single-hop TLS are unclear,
http://bugs.sipit.net/show_bug.cgi?id=734",
September 2003.
[BUG735] Sparks, RS., "Bug 735: Record-route manipulation rules for
responses wrt SIPS vs hop-hop TLS are incorrect,
http://bugs.sipit.net/show_bug.cgi?id=735",
September 2003.
[I-D.drage-sip-essential-correction]
Drage, K., "A Process for Handling Essential Corrections
to the Session Initiation Protocol (SIP)",
draft-drage-sip-essential-correction-01 (work in
progress), March 2007.
[I-D.ietf-sip-sips]
Audet, F., "The use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", draft-ietf-sip-sips-06 (work
in progress), August 2007.
[I-D.ietf-sipping-v6-transition]
Camarillo, G., "IPv6 Transition in the Session Initiation
Protocol (SIP)", draft-ietf-sipping-v6-transition-07 (work
in progress), August 2007.
[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
Froment & Lebel Expires May 12, 2008 [Page 23]
Internet-Draft SIP Record-Route fix November 2007
Initiation Protocol (SIP)", RFC 3323, November 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.
Froment & Lebel Expires May 12, 2008 [Page 24]
Internet-Draft SIP Record-Route fix November 2007
Authors' Addresses
Thomas Froment
Alcatel-Lucent
Centre de Villarceaux, Route de Villejust
Nozay, Paris 91620
France
Email: Thomas.Froment@alcatel-lucent.fr
Christophe Lebel
Alcatel-Lucent
Lieu dit Le Mail
Orvault, 44708
France
Email: Christophe.Lebel@alcatel-lucent.fr
Froment & Lebel Expires May 12, 2008 [Page 25]
Internet-Draft SIP Record-Route fix November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Froment & Lebel Expires May 12, 2008 [Page 26]
