SIP Extension Header for Service Route Discovery in Private Networks
dynamicsoft Inc.
5100 Tennyson ParkwaySuite 1200PlanoTX75028US+1 972 473 5455dwillis@dynamicsoft.comhttp://www.dynamicsoft.com/
Nokia
Helsinki, Hiomo 3/6P.O. Box 31200045 NOKIA GroupFinland+358-40-821 9 831bernhard.honeisen@nokia.com, b.hoeneisen@ieee.orghttp://www.nokia.com/
Transport
SIP -- Session Initiation Protocol Working GroupSIPPathREGISTERContact3GPPservicerouteThis document proposes a private SIP extension header used
in conjunction with responses to REGISTER messages 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.3GPP established a requirement for discovering home proxies
during SIP registration and published this requirement in draft-garcia-sipping-3gpp-reqs .
Unlike many other network environments, 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 messages having a request-URI targeting the
address-of-record associated with the UA to the assigned home
service proxy by using some sort of look-up-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 have been 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 a significant additional "over the air" traffic.Use of lookup tables in the home network, as is done for
inbound messages. 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 message 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 messages 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 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 discusses this final alternative: using a
header 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. 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 messages
from UA1 may be routed (at the discretion of UA1) through HSP,
thereby receiving outbound services from HSP. The proposed mechanism uses a private header
"P-Service-Route" 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. The routing established by the P-Service-Route
mechanism applies only to 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 that the registering UA may use to send messages through
the service proxy selected by the registrar. The UA would use
this route by inserting it as a preloaded Route header in
messages originated by the UA intended for routing through the
service proxy.The mechanism by which the registrar constructs the header
value is specific to the local implementation and outside the
scope of this document.The P-Service-Route mechanism is applicable when:The UA registers with a REGISTRAR in a given domain.The domain dynamically assigns a service proxy for the UA.The registrar(s) in the domain 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
administrative domain.The syntax for the P-Service-Route header is:P-Service-Route = "P-Service-Route" HCOLON 1#( p-sr-value)p-sr-value = name-addr *( SEMI rr-param )rr-param = generic-paramThe allowable usage of headers is described in Tables 2 and 3
of SIPbis . The following additions
to this table are needed for P-Service-Route.The UA performs a register as usual. The register response
may contain a P-Service-Route header. If so, the UA MAY store
the value of the P-Service-Route header in an association with
the address-of-record for which the REGISTER message had
registered a contact. If the UA supports multiple address of
records, 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 P-Service-Route is updated according
to the P-Service-Route header of the latest 200 OK
response. If there is no P-Service-Route header in the
response, the UA clears any service route for that registrar
previously stored by the UA.
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 poilicy in order to
get a workable system.A Fetching Bindings operation, i.e. no
Contact header field is present in the REGISTER request,
does not affect any stored value of P-Service-Route.The UA MAY choose to exercise a service route for future
messages associated with a given address-of-record for which a
service route is known. If so, it appends the given service
route to any locally required Route headers, and uses the result
as a preloaded Route header in outgoing messages. The UA MUST
preserve the order, in case there is more than one
P-Service-Route header or element.The P-Service-Route header is generally treated like any other
unknown header by intermediate proxies. They simply forward it
on towards the destination.There is a question of whether proxies processing a
REGISTER response may add themselves to the route set in the
P-Service-Route header. 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 P-Service-Route in
REGISTER responses, and if they do, acceptance of the
alteration by the UA MUST NOT be required.When a registrar receives a successful REGISTER message, it
MAY choose to return one or more P-Service-Route header(s) in
the 200 OK response. The determinations of whether to include
these header(s) into the 200 OK response and what value(s) to
insert are a matter of local policy and outside the scope of
this document.Having inserted a P-Service-Route header, the registrar
returns the 200 OK response to the UA in accordance with
standard procedures.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 P-Service-Route
header or element in the 200 OK response; the order is
specified as top-down, meaning the topmost P-Service-Route
entry will be visited first. Such constructions are
implementation specific and outside the scope of this
document.In general, the P-Service-Route header 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 registar cannot be assumed to have
knowledge of the topology of the visited network, so the
P-Service-Route it returns contains elements only within the
home network.Note that the inserted P-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
P-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 approprate 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 HOMEDOMAIN, where UA1 has
previously registered with HOMEDOMAIN and been informed of a
service route through HSP. The service being provided by
HOMEDOMAIN 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
P-Service-Route returned by the registrar, or to insert a
P-Service-Route even when one was not returned by the
registrar. 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
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 message, S/MIME signed bodies
may be used to provide end-to-end protection for the returned
value. Systems using P-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
P-Service-Route SHOULD provide end-to-end protection on the
return using S/MIME. UAs receiving P-Service-Route SHOULD
authenticate attached S/MIME bodies.This document defines the SIP extension header
"P-Service-Route" which should be included in the registry of
SIP headers defined in SIP bis .
As required by the SIP change process draft-tsvarea-sipchange the SIP
extension header name "Service-Route" should also be registered
in association with this extension. However, "Service-Route"
MUST not be used until documented by a standards-track
RFC. Expert review as required for this process is to be
provided by the SIP Working Group.SIP: Session Initiation Protocoldynamicsoft Inc.3GPP Requirements On SIPSIP Change Process