Session Initiation Protocol Extension Header Field for Service Route Discovery During Registration
dynamicsoft Inc.
5100 Tennyson ParkwaySuite 1200PlanoTX75028US+1 972 473 5455dwillis@dynamicsoft.comhttp://www.dynamicsoft.com/
Switch
Limmatquai 138CH-8001 ZuerichSwitzerland+41 1 268 1515hoeneisen@switch.ch, b.hoeneisen@ieee.orghttp://www.switch.ch/
Transport
SIP -- Session Initiation Protocol Working GroupSIPPathREGISTERContact3GPPservicerouteThis document defines a SIP extension header field used in
conjunction with responses to REGISTER requests to provide a
mechanism by which a registrar may inform a registering UA of
a service route that the UA may use to request outbound
services from the registrar's domain.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.3GPP established a requirement for discovering home proxies
during SIP registration and published this requirement in draft-garcia-sipping-3gpp-reqs . The
3GPP network dynamically assigns a home service proxy to each
address-of-record. This assignment may occur in conjunction with
a REGISTER operation, or out-of-band as needed to support call
services when the address-of-record has no registrations. This
home service proxy may provide both inbound (UA terminated) and
outbound (UA originated) services.For inbound (UA terminated) session cases, the home proxy
network routes requests having a request-URI targeting the
address-of-record associated with the UA to the assigned home
service proxy by using a mechanism outside the scope of this
document.Outbound (UA originated) session cases raise another issue.
Specifically, "How does the UA know which service proxy to use
and how to get there?"Several mechanisms were proposed in list discussions,
including:Configuration data in the UA. This raises questions of UA
configuration management and updating, especially if proxy
assignment is very dynamic, such as in load-balancing
scenarios.Use of some other protocol, such as HTTP, to get
configuration data from a configuration server in the home
network. While functional, this solution requires additional
protocol engines, firewall complexity, operations overhead,
and significant additional "over the air" traffic.Use of lookup tables in the home network, as may be done
for inbound requests in some 3G networks. This has a
relatively high overhead in terms of database operations.Returning a 302 response indicating the service proxy as a
new contact, causing the upstream node processing the 302
(ostensibly the UA) to retransmit the request toward the
service proxy. While this shares the database operation of the
previous alternative, it does explicitly allow for caching the
302 response thereby potentially reducing the frequency and
number of database operations.Performing an operation equivalent to record-routing in a
REGISTER transaction between the UA and the associated registrar,
then storing that route in the UA and reusing it as a service
route on future requests originating from the UA. While
efficient, this constrains the service route for proxy
operations to be congruent with the route taken by the
REGISTER message. Returning service route information as the value of a
header field in the REGISTER response. While similar to the
previous alternative, this approach grants the ability for the
registrar to selectively apply knowledge about the topology of
the home network in constructing the service route.This document defines this final alternative: using a
header field in the REGISTER response to indicate a service
route that the UA may wish to use if requesting services from
the proxy network associated with the registrar generating the
response. In this scenario, we have a "home network" containing routing
proxy P2, registrar R, home service proxy HSP, and database DBMS
used by both R and HSP. P2 represents the "edge" of the home
network from a SIP perspective, and might be called an "edge
proxy". UA1 is an external UA behind proxy P1. UA1 discovers P1
via DHCP (this is just an example, and other
mechanisms besides DHCP are possible). UA2 is another UA on the
Internet, and does not use a default outbound proxy. We do not
show DNS elements in this diagram, but will assume their
reasonable availability in the discussion.
The mission is for UA1 to discover HSP so that outbound requests
from UA1 may be routed (at the discretion of UA1) through HSP,
thereby receiving outbound services from HSP. The mechanism documented here uses a header field
"Service-Route" in the REGISTER response to indicate a service
route that the UA may use when requesting services from the
proxy network associated with the registrar generating the
response. The routing established by the Service-Route
mechanism applies only to requests originating in the user
agent.Simply put, the registrar generates a service route for the
registering UA and returns it in the response to each successful
REGISTER request. This service route has the form of a Route
header field that the registering UA may use to send requests
through the service proxy selected by the registrar. The UA
would use this route by inserting it as a preloaded Route header
field in requests originated by the UA intended for routing
through the service proxy.The mechanism by which the registrar constructs the header
field value is specific to the local implementation and outside
the scope of this document.The Service-Route mechanism is applicable when:The UA registers with a registrar.The registrar has knowledge of a service proxy that
should be used by the UA when requesting services from the
domain of the registrar. This knowledge may be a result of
dynamic assignment or some other mechanism outside the
scope of this document. The registrar(s) has/have sufficient knowledge of the
network topology, policy, and situation such that a
reasonable service route can be constructed.Other mechanisms for proposing a service route to the UA
are not available or are inappropriate for use within the
specific environment. Other methods may also be available by which a UA may be
informed of a service route. Such alternative methods are
outside the scope of this document. Discussion of why one
might wish to assign a service route during registration or
when it might be appropriate to do so is outside the scope of
this document.The syntax for the Service-Route header field is:Service-Route = "Service-Route" HCOLON sr-value *( COMMA
sr-value)sr-value = name-addr *( SEMI rr-param )rr-param = generic-paramThe allowable usage of header fields is described in Tables 2
and 3 of RFC 3261 . The following
additions to this table are needed for Service-Route.The UA performs a registration as usual. The REGISTER response
may contain a Service-Route header field. If so, the UA MAY
store the value of the Service-Route header field in an
association with the address-of-record for which the REGISTER
transaction had registered a contact. If the UA supports
multiple addresses-of-record, it may be able to store multiple
service routes, one per address-of-record. If the UA refreshes
the registration, the stored value of the Service-Route is
updated according to the Service-Route header field of the
latest 200 class response. If there is no Service-Route header
field in the response, the UA clears any service route for
that registrar previously stored by the UA. If the
re-registration request is refused or if an existing
registration expires and the UA chooses not to re-register,
the UA SHOULD discard any stored service route for that
address-of-record.
The UA MAY choose to exercise a service route for future
requests associated with a given address-of-record for which a
service route is known. If so, it uses the content of the
Service-Route header field as a preloaded Route header field
in outgoing initial requests . The UA
MUST preserve the order, in case there is more than one
Service-Route header field or header field value.Loose routes may interact with routing policy in
interesting ways. The specifics of how the service route set
integrates with any locally required default route and local
policy are implementation dependent. For example, some devices
will use locally-configured explicit loose routing to reach a
next-hop proxy, and others will use a default outbound-proxy
routing rule. However, for the result to function, the
combination MUST provide valid routing in the local
environment. In general, the service route set is appended to
any locally configured route needed to egress the access proxy
chain. Systems designers must match the service routing policy
of their nodes with the basic SIP routing policy in order to
get a workable system.The Service-Route header field is generally treated like
any other unknown header field by intermediate proxies. They
simply forward it on towards the destination. Note that, as
usual, intermediate proxies that need to be traversed by
future requests within a dialog may record-route. Proxies
should not assume that they will be traversed by future
requests in a dialog simply because they appear in the
Service-Route header field.There is a question of whether proxies processing a
REGISTER response may add themselves to the route set in the
Service-Route header field. While this would enable dynamic
construction of service routes, it has two significant
problems. The first is one of transparency, as seen by the
registrar: Intermediate proxies could add themselves without
the knowledge or consent of the registrar. The second problem
is interaction with end-to-end security. If the registrar uses
S/MIME techniques to protect the REGISTER response, such
additions would be visible to the UA as "man in the middle"
alterations in the response. Consequently, intermediate
proxies SHOULD NOT alter the value of Service-Route in
REGISTER responses, and if they do, acceptance of the
alteration by the UA MUST NOT be required.Additional considerations apply if a proxy is "dual homed",
meaning connected to two (or more) different networks such
that requests are received on one interface and proxied out
through another network interface. Proxies implementing
multi-homing precisely as documented in RFC 3261 record-route a request with
the sending interface. When processing the reply, they replace
the Record-Route header field value that represents the
interface onto which they proxied the request with a new value
that represents the interface onto which they will proxy the
response. Consequently, the route vector seen at the UAS is
not the exact inverse of the route vector seen at the
UAC. While in itself harmless, this complicates matters for
nodes that use the recorded route vector (or recorded Path
vector) in the determination of a service route for future
use.Instead of following the procedure in RFC 3261, proxies used with
Service-Route that are inserting Record-Route or Path header
field values SHOULD record not one but two route values when
processing the request. The first value recorded indicates the
receiving interface, and the second indicates the sending
interface. When processing the response, no modification of
the recorded route is required. This optimization provides for
fully invertable routes that can be effectively used in
construction of servcie routes.When a registrar receives a successful REGISTER request, it
MAY choose to return one or more Service-Route header
field(s) in the 200 class response. The determination(s) of
whether to include these header fields(s) into the 200 class
response and what value(s) to insert are a matter of local
policy and outside the scope of this document.Having inserted a Service-Route header field or fields,
the registrar returns the 200 class response to the UA in
accordance with standard procedures.A REGISTER operation performing a Fetching Bindings
(i.e. no Contact header field is present in the request)
SHOULD return the same value of Service-Route as returned in
the corresponding previous REGISTER response for the
address-of-record in question. In some cases, the
Service-Route may be dynamically calculated by the registrar
rather than stored, and the decision as to whether this route
should be recalculated in the event of a Fetching Bindings
operation is left to the implementation.A Fetching Bindings operation could be
used by the UA to recover a lost value of
Service-Route. Or, a UA in this situation could just
re-REGISTER.Certain network topologies MAY require a specific proxy
(e.g. firewall proxy) to be traversed before the home service
proxy. Thus, a registrar with specific knowledge of the
network topology MAY return more than one Service-Route header
field or element in the 200 class response; the order is
specified as top-down, meaning the topmost Service-Route entry
will be visited first. Such constructions are implementation
specific and outside the scope of this document.In general, the Service-Route header field contains
references to elements strictly within the administrative
domain of the registrar and home service proxy. For example,
consider a case where a user leaves the "home" network and
roams into a "visited" network. The registrar cannot be
assumed to have knowledge of the topology of the visited
network, so the Service-Route it returns contains elements
only within the home network.Note that the inserted Service-Route element(s) MUST
conform to the syntax of a Route element as defined in . As suggested therein, such route elements
MUST include the loose-routing indicator parameter ";lr" for
full compliance with We present an example in the context of the scenario
presented in the Background section earlier in this
document. The network diagram is replicated below:This example shows the message sequence for user agent UA1
registering to HOMEDOMAIN using registrar R. R returns a
Service-Route indicating that UA1 may use home service proxy
HSP to receive outbound services from HOMEDOMAIN.Please note that the name UA1, HOMEDOMAIN, etc. are
placeholders for appropriate user and host names or
addresses.This example shows the message sequence for an INVITE
transaction originating from UA1 eventually arriving at UA2
using outbound services from EXAMPLEHOME.COM, where UA1 has
previously registered with EXAMPLEHOME.COM and been informed of a
service route through HSP. The service being provided by
EXAMPLEHOME.COM is a "logging" service, which provides a record
of the call for UA1's use (perhaps the user of UA1 is an
attorney who bills for calls to customers).It is possible for proxies between the UA and the registrar
during the REGISTER transaction to modify the value of
Service-Route returned by the registrar, or to insert a
Service-Route even when one was not returned by the
registrar. The consequence of such an attack is that future
requests made by the UA using the service route might be
diverted to or through a node other than would normally be
visited. It is also possible for proxies on the INVITE path to
execute many different attacks. It is therefore desirable to
apply transitive mutual authentication using sips: or other
available mechanisms in order to prevent such attacks. The "sips:" URI as defined in RFC
3261 defines a mechanism by which a UA may request
transport-level message integrity and mutual
authentication. Since there is no requirement for proxies to
modify messages, S/MIME signed bodies may be used to provide
end-to-end protection for the returned value. Systems using Service-Route SHOULD provide hop-by-hop
message integrity and mutual authentication. UAs SHOULD request
this support by using a "sips:" URI. Registrars returning a
Service-Route SHOULD provide end-to-end protection on the
return using S/MIME. UAs receiving Service-Route SHOULD
authenticate attached S/MIME bodies.This document defines the SIP extension header field
"Service-Route" which shall be included in the registry of SIP
header fields defined in RFC 3261
. The working process of the SIP
Change Process mandates that general SIP extension header
fields be defined by a standards-track RFC. This document
provides the required definition.The following is the registration for the Service-Route
header field:
RFCXXXX [Note to IANA: Fill in
with the RFC number of this specification.]Service-Routenone3GPP Requirements On SIPSIP Change Process