[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

SIP                                                         J. Rosenberg
Internet-Draft                                             Cisco Systems
Expires: January 12, 2006                                  July 11, 2005


    Clarifying Construction of the Route Header Field in the Session
                       Initiation Protocol (SIP)
                 draft-rosenberg-sip-route-construct-00

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 January 12, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The Route header field in the Session Initiation Protocol (SIP)
   protocol is used to cause a request to visit a set of hops on its way
   towards the final destination.  The SIP specification defines
   construction of the Route header field at user agents.  However,
   numerous other mechanisms have been described, such as Service-Route
   and the 305 response, which cause the client to set its Route header
   field for a request.  As such, the specific behavior for a UA in
   construction of its Route header field is unclear.  This document



Rosenberg               Expires January 12, 2006                [Page 1]


Internet-Draft               Route Construct                   July 2005


   attempts to define a consistent set of logic.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Existing Sources . . . . . . . . . . . . . . . . . . . . . .   3
     2.1  Default Outbound Proxies . . . . . . . . . . . . . . . . .   3
     2.2  Service Route  . . . . . . . . . . . . . . . . . . . . . .   4
     2.3  Record-Routes  . . . . . . . . . . . . . . . . . . . . . .   4
     2.4  305 Use Proxy  . . . . . . . . . . . . . . . . . . . . . .   4
   3.   Problems with Current Specifications . . . . . . . . . . . .   5
   4.   Overview of Operation  . . . . . . . . . . . . . . . . . . .   6
   5.   Detailed Processing Rules  . . . . . . . . . . . . . . . . .   6
     5.1  Registrar Behavior . . . . . . . . . . . . . . . . . . . .   6
     5.2  UAC Behavior . . . . . . . . . . . . . . . . . . . . . . .   7
     5.3  Client Behavior  . . . . . . . . . . . . . . . . . . . . .   7
     5.4  Server Behavior  . . . . . . . . . . . . . . . . . . . . .   8
   6.   Backwards Compatibility  . . . . . . . . . . . . . . . . . .   9
   7.   Security Considerations  . . . . . . . . . . . . . . . . . .  10
   8.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  10
   9.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  10
   10.  References . . . . . . . . . . . . . . . . . . . . . . . . .  11
     10.1   Normative References . . . . . . . . . . . . . . . . . .  11
     10.2   Informative References . . . . . . . . . . . . . . . . .  11
        Author's Address . . . . . . . . . . . . . . . . . . . . . .  11
        Intellectual Property and Copyright Statements . . . . . . .  12

























Rosenberg               Expires January 12, 2006                [Page 2]


Internet-Draft               Route Construct                   July 2005


1.  Introduction

   The Route header field in the Session Initiation Protocol (SIP)
   protocol is used to cause a request to visit a set of hops on its way
   towards the final destination.  RFC 3261 [2] discusses how a client
   constructs the Route header field for requests.  However, this logic
   is restricted to mid-dialog requests, where the route set was learned
   as a result of record-routing.

   However, additional sources of routes can exist for a UA.  These
   include default outbound proxies, a service route learned from the
   Service-Route header field [3], and a redirection coming from a 305
   response.  In total, there are four sources of potential route
   headers.  The way in which these various sources are reconciled is
   unclear.  Furthermore, the various specifications are unclear about
   which requests these Route headers are applicable to.  Do they apply
   to REGISTER?  Do they apply to mid-dialog requests?

   Section 2 reviews the existing sources of route sources.  Section 3
   discusses problems with the existing specifications.  Section 4
   overviews the proposed changes in behavior.  Section 5 provides a
   detailed description of element behavior, and Section 6 discusses
   backwards compatibility issues.

2.  Existing Sources

   This section examines the current set of route header field sources.

2.1  Default Outbound Proxies

   RFC 3261 discusses default outbound proxies.  In Section 8.1.1.1, it
   makes reference to its interaction with Route header fields:

      In some special circumstances, the presence of a pre-existing
      route set can affect the Request-URI of the message.  A pre-
      existing route set is an ordered set of URIs that identify a chain
      of servers, to which a UAC will send outgoing requests that are
      outside of a dialog.  Commonly, they are configured on the UA by a
      user or service provider manually, or through some other non-SIP
      mechanism.  When a provider wishes to configure a UA with an
      outbound proxy, it is RECOMMENDED that this be done by providing
      it with a pre-existing route set with a single URI, that of the
      outbound proxy.

      When a pre-existing route set is present, the procedures for
      populating the Request-URI and Route header field detailed in
      Section 12.2.1.1 MUST be followed (even though there is no
      dialog), using the desired Request-URI as the remote target URI.



Rosenberg               Expires January 12, 2006                [Page 3]


Internet-Draft               Route Construct                   July 2005


   The default outbound proxy can be learned either through DHCP [4],
   through configuration (such as the SIP configuration framework [6]),
   or through other means.  In the IMS, the default outbound proxy is
   the P-CSCF and is learned through GPRS specific techniques.

   RFC 3261 does not explicitly say the set of messages to which this
   route set applies.  However, the text above implies that it is for
   all requests outside of a dialog.

2.2  Service Route

   RFC 3608 specifies the Service-Route header field.  This header field
   is provided to the UA in a 2xx response to a REGISTER request.  The
   client uses this to populate its Route header fields for outgoing
   requests.  However, RFC 3608 explicitly says that the decision a UA
   makes about how it combines the service route with other outbound
   routes is a matter of local policy.  Furthermore, RFC 3608 does not
   clearly define to which requests the service route applies, and in
   particular, whether or not it applies to a REGISTER request or a mid-
   dialog request.

2.3  Record-Routes

   RFC 3261 provides a detailed description of the record-routing
   mechanism, and how the user agents in a dialog construct route sets
   from the Record-Route header field values.  RFC 3261 is also clear
   that the resulting route set applies to mid-dialog requests.  It
   implies (though does not explicitly say) that the resulting route set
   overrides any default outbound proxies (which represent a pre-loaded
   route set).

2.4  305 Use Proxy

   RFC 3261 defines the 305 "Use Proxy" response code, but says
   extremely little about exactly how it is used.  It has this to say:

      The requested resource MUST be accessed through the proxy given by
      the Contact field.  The Contact field gives the URI of the proxy.
      The recipient is expected to repeat this single request via the
      proxy. 305 (Use Proxy) responses MUST only be generated by UASs.

   It is unclear how the Contact in the redirect is used.  Does it
   populate the request URI of the resulting request?  Or, does it get
   used to populate the Route header field?  The restriction to UASs is
   also not explained.

   Historically, the reason for the restriction to UAs was to avoid
   routing loops.  Consider an outbound proxy that generates a 305,



Rosenberg               Expires January 12, 2006                [Page 4]


Internet-Draft               Route Construct                   July 2005


   instead of proxying the request.  The concern was that the client
   would then recurse on the response, populate the Contact into a new
   request URI, and send the request to its default outbound proxy,
   which redirects once more.  To avoid this, the RFC says that only a
   UAS can redirect with a 305, not a proxy.

   However, this design decision on 305 handling was made prior to the
   conception of loose routing, although both ended up in RFC 3261.  The
   design of the 305 mechanism, unfortunately, was not revisited after
   loose routing was specified.  As such, the draft is not clear about
   whether or not the contact gets utilized as a Route header field
   value or whether it replaces the Request URI.

3.  Problems with Current Specifications

   Because the interactions between these various sources of routes are
   unspecified, certain features have proven impossible to provide,
   and/or interoperability problems have resulted.

   One problem is that, depending on the way a client constructs its
   route set, it may be impossible to change a users outbound proxy
   without updating its configuration.  Such changes are extremely
   useful for many operational reasons.  One example is movement of
   subscribers between geographically distributed sites in cases where a
   site must be gracefully taken out of service, and the subscribers
   using it need to be moved.  If the client uses the service route to
   augment the route from corresponding to its default outbound proxy, a
   network provider cannot move a subscriber.

   Another problem is the client bootstrapping problem.  Consider the
   same SIP network that utilizes geographically distributed sites.
   Each site contains a subset of the user database - the subset for the
   users in that site.  When a SIP UA first boots up, it needs to obtain
   its configuration.  As such, it has a hard-coded default proxy it
   uses for an initial SUBSCRIBE to enroll in its configuration [6].
   This proxy, however, may not be the one in site to which the user of
   that SIP UA is associated.  Ideally, the initial SUBSCRIBE could be
   routed to a server that redirects the client to the right proxy in
   the user's actual site.  This redirection needs to override the
   default outbound proxy for the phone.  However, there is not
   currently a way to do that.

   An interoperability problem that has arisen is keeping an outbound
   proxy on the path for outbound requests.  Consider a proxy in a hotel
   which a client discovers via DHCP and uses as its outbound proxy.
   This proxy wishes to be used for incoming and outgoing requests, both
   in and out of a dialog.  So, it includes itself on the Path header
   field of the REGISTER.  However, it has no idea if the registrar will



Rosenberg               Expires January 12, 2006                [Page 5]


Internet-Draft               Route Construct                   July 2005


   reflect the Path header field into the Service-Route, and cannot
   determine whether putting itself on the Path is effective for getting
   on the service route.  Per RFC 3608 it cannot modify the Service-
   Route in the response to REGISTER.  As such, if the registrar does
   not include the proxy in the Service-Route, and the endpoint
   overrides its outbound proxy setting with the Service-Route, the
   local proxy falls off the outbound path despite its best efforts.

4.  Overview of Operation

   Firstly, new behavior for generation and processing of the 305 Use
   Proxy is specified.  Any element in the network, proxy or UAS, can
   generate a 305, not just a UAS as specified in RFC3261.  This
   redirect can be recursed by any upstream element, but it is ideally
   recursed by the element directly upstream from the one that genreated
   the redirect.  To recurse on the redirect, the proxy or UAC takes the
   Contact header field value from the 305, and uses it to replace the
   top value of the Route header field used previously.  If no Route
   header field was used previously, one is added.  However, in neither
   case is the Request-URI modified.

   When a UAC goes to send a request, whether it is a mid-dialog request
   or a new request with any method (except CANCEL or ACK to a non-2xx
   response), the client first uses any route set learned from a record-
   route (which covers mid-dialog requests).  If the request is not a
   mid-dialog reuqest, the client sees if it has any service routes
   learned through RFC 3608.  If there are none, the client next uses
   any configured default outbound proxies.  These three sources -
   record-routes, service routes and default outbound proxies - are
   never mixed, and one and only one of them applies to each request.
   After it is applied however, if the request results in a 305 Use
   Proxy response, the topmost Route header field is updated as
   described above.

   A registrar, upon receipt of a REGISTER, uses the Path header field
   values to construct the Service-Route in the response.  The values
   from the Path are copied into the Service-Route, and the registrar
   can then add some additional ones if they are within the domain of
   the provider.

5.  Detailed Processing Rules

5.1  Registrar Behavior

   The registrar MUST construct the Service-Route in the registration
   response by taking each URI from the Path header field in the
   REGISTER request, and inverting the order.  After inversion, the
   registrar MAY add additional URIs at the end of the list (that is,



Rosenberg               Expires January 12, 2006                [Page 6]


Internet-Draft               Route Construct                   July 2005


   the right hand side of the list, corresponding to proxy elements that
   will be the farthest away from the UA).

   Furthermore, the registrar MAY replace or remove any URIs that are
   within a domain under the control of the registrar.  When replacing a
   URI, one or more new ones can take its place.  If the registrar is in
   example.com, this would include any URIs whose domain part is
   example.com.  It would also include any URIs whose domain is a
   subdomain of example.com, as long as that subdomain is under the
   control of example.com.  It could also include URIs whose domain part
   is unrelated to example.com, as long as those are within the control
   of example.com.  It is difficult to provide a concise definition of
   "under the control", but generally it means that the administrative
   policies for the subservient domain are completely defined by the
   controlling domain.

   This behavior ensures that proxies outside of the domain of the
   registrar have a way to appear on the service route, but provides a
   way, within a domain, to provide service routes that are not coupled
   to the Path.

5.2  UAC Behavior

   A UAC compliant to this specification MUST include the "lr305" option
   tag in the Supported header field of requests that it generates.

   For a request sent by a UAC that is not the result of recursion on a
   305, the following logic MUST be used to compute the route set used
   to populate the Route header field of the request.  If the request is
   a mid-dialog request, the route set is computed per the procedures in
   Section 12.2.1.1 of RFC 3261.  This route set overrides routes
   learned from configuration, DHCP, Service-Route or any other
   mechanism.  If the request is not a mid-dialog request, the client
   checks to see if it has learned a service route as a result of
   registering the AOR it has populated in the From header field of the
   request.  If it has learned a service route, the URIs from the
   Service-Route header field is used as the route set for the request.
   This route set overrides routes learned from configuration, DHCP, or
   any other mechanism.  This route set is used in all requests outside
   of a dialog, including REGISTER.  If the UA has not learned a service
   route, it uses the route set learned through configuration.  [[OPEN
   ISSUE: Do we need to specify how to reconcile route sources learned
   across disparate configuration sources?  For example DHCP and a
   config file?]]

5.3  Client Behavior

   The following logic defined here applies to all clients, both UAC and



Rosenberg               Expires January 12, 2006                [Page 7]


Internet-Draft               Route Construct                   July 2005


   proxies, and applies to the processing of a 305 response.

   It is RECOMMENDED that a client in receipt of a 305 recurse on that
   redirection, rather than forwarding it upstream.  To compute the
   request that is sent as a result of the recursion, the client MUST
   take the route set used for the request that generated the 305
   response.  If that request had a Route header field, the first value
   MUST be replaced with the value of the Contact header field in the
   305 with the highest q-value.  If there are multiple such Contacts
   with the same q-value, one is chosen at random.  The result is used
   as the route set for the new request.  If the original request did
   not have a Route header field, the new request MUST contain a single
   Route header field value, equal to the URI provided in the Contact
   header field of the 305 with the highest q-value.  This processing
   applies to requests both inside and outside of a dialog, and applies
   to all request methods, including REGISTER, with the exception of ACK
   and CANCEL.

   If a 305 response had multiple Contact header field values, and the
   recursed request generated a 503 response, and the client had
   exhausted all alternative servers learned from DNS [5] for the
   previous Contact header field value, the client SHOULD choose the
   Contact from the 305 with the next highest q-value, and construct
   another recursed request using the procedures defined above.  In the
   event the 305 had multiple Contact header field values with
   equivalent q-values, the next highest one might have a q-value equal
   to the one that was just tried.

   If the policy of the client is such that it a request must visit a
   particular set of hops subsequent to being processed, and the route
   set constructed as a result of the recursion does not meet those
   policy constraints, the client MAY push additional route header field
   values in order for the request to meet those policy requirements.
   Proxies that do this SHOULD verify that the URI placed into the
   topmost Route header field value is an acceptable next hop, and not
   just blindly push route header field values.

5.4  Server Behavior

   Any server, either a UAS or a proxy, MAY generate a 305 in response
   to a request.  Such a response can be generated either for initial or
   mid-dialog requests.  The 305 SHOULD NOT be generated unless one of
   the following conditions is met:

   o  The server generating the 305 has an administrative relationship
      with the previous hop element, and knows that it is capable of
      supporting this specification and will recurse on a 305 that it
      sends.



Rosenberg               Expires January 12, 2006                [Page 8]


Internet-Draft               Route Construct                   July 2005


   o  The server generating the 305 believes that its previous hop is a
      UAC, and the request being redirected included a Supported header
      field with the option tag "lr305".

   These requirements provide a limited form of backwards compatibility.
   See Section 6 for a thorough discussion.

6.  Backwards Compatibility

   This specification defines a different behavior for the processing of
   305 than is implied in RFC 3261 (although the behavior is not
   entirely clear).  Because of this, there are two backwards
   compatibility scenarios that need to be considered:

   1.  The element that recurses on the redirection does not support
       this specification.  As a result, it replaces its Request-URI in
       the recursed request with the value from the Contact header field
       of the 305.

   2.  The element that recurses supports this specification, and
       correctly populates the Contact header field value into the Route
       header field of the recursed request.  However, the element that
       performed the recursion was not the element immediately upstream
       from the one that generated the 305.  As a result, an
       intermediate element is bypassed even though the desire was for
       it to remain on the route set.

   The first of these two cases causes the Request URI to be clobbered.
   The request will arrive at the server that was the target of the
   redirection, but it probably won't be able to process the request
   because the actual request URI is no longer present.  Unfortunately,
   avoiding this failure case entirely is quite difficult.  It requires
   the redirecting server to have an assurance that the element
   immediately upstream, whether it is a proxy or UAC, supports this
   specification.  There is no mechanism in the suite of RFC 3261
   compatibility tools that can provide such a function.  The only way
   to do this is to include another cookie in the Via branch ID, used as
   a signal that this extension is supported.  However, this results in
   substantial pollution of the Via header field, and increases each
   message substantially.

   It is believed that a 305 redirection is in fairly limited usage at
   the time of writing, and so this specification provides a weaker form
   of backwards compatibility.  The Supported header field is used to
   verify that clients support the mechanism.  Rather than explicit
   signaling, it is assumed that proxies can know whether the previous
   hop supports this mechanism based on an administrative relationship
   with that proxy.  This precludes 305 from being used inter-provider



Rosenberg               Expires January 12, 2006                [Page 9]


Internet-Draft               Route Construct                   July 2005


   until it is ubiquitously deployed.  However, this does not seem like
   a major limitation, since most of the use cases are intra-provider.
   The backwards compatibility mechanism also assumes that a proxy can
   determine that its previous hop is a UAC as opposed to a proxy; this
   is hard to know for certain.

   The second backwards compatibility issue is interesting.  What
   happens if the 305 is properly handled, but is recursed by an element
   that lies multiple hops upstream from the redirecting server?  The
   recursing element will replace its top Route header field with the
   value from the Contact in the 305, and presumably send the request
   there directly.  That may or may not be a problem, it depends on
   whether the previously-intervening proxies really need to be on the
   request path or not.  To deal with this case, the specification
   allows a recursing element to push additional route headers in order
   to make sure requests traverse paths that meet their policy
   constraints.

7.  Security Considerations

   An attacker that injects a fake route set, whether it is in a 305
   response, a Service-Route, a Record-Route or a configuration, can
   launch a multitude of attacks, including denial-of-service and fraud.
   For this reason, an element SHOULD NOT make use of a route set unless
   it has obtained it through a signaling channel that has been secured
   using the SIPS mechanism in RFC 3261 [2]

8.  IANA Considerations

   This specification registers a new option tag for SIP, according to
   Section 27.1 of RFC 3261.

   Name: lr305

   Description: This option tag is for support of the loose routing
      behavior for the 305 Use Proxy response.  It is used in the
      Supported header field of requests, and indicates that the UAC
      will properly recurse when it receives a 305.


9.  Acknowledgements

   The author would like to thank Paul Kyzivat and Anders Kristensen for
   their comments.

10.  References





Rosenberg               Expires January 12, 2006               [Page 10]


Internet-Draft               Route Construct                   July 2005


10.1  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  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.

   [3]  Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
        Extension Header Field for Service Route Discovery During
        Registration", RFC 3608, October 2003.

10.2  Informative References

   [4]  Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP-for-
        IPv4) Option for Session Initiation Protocol (SIP) Servers",
        RFC 3361, August 2002.

   [5]  Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
        (SIP): Locating SIP Servers", RFC 3263, June 2002.

   [6]  Petrie, D., "A Framework for Session Initiation Protocol User
        Agent Profile Delivery", draft-ietf-sipping-config-framework-06
        (work in progress), February 2005.


Author's Address

   Jonathan Rosenberg
   Cisco Systems
   600 Lanidex Plaza
   Parsippany, NJ  07054
   US

   Phone: +1 973 952-5000
   Email: jdrosen@cisco.com
   URI:   http://www.jdrosen.net













Rosenberg               Expires January 12, 2006               [Page 11]


Internet-Draft               Route Construct                   July 2005


Intellectual Property Statement

   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.


Disclaimer of Validity

   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 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.


Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Rosenberg               Expires January 12, 2006               [Page 12]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/