SIP                                                             K. Johns
Internet-Draft                                                 CableLabs
Intended status: Standards Track                        January 31, 2007
Expires: August 4, 2007


           Routing of mid dialog requests using sip-outbound
              draft-johns-sip-outbound-middialog-draft-02

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 August 4, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).














Johns                    Expires August 4, 2007                 [Page 1]

Internet-Draft         Mid dialog request routing           January 2007


Abstract

   This document describes a solution for routing of mid-dialog requests
   in the presence of NATs.  The solution leverages and extends the
   concepts described in the Internet Draft titled Managing Client
   Initiated Connections in the Session Initiation Protocol.  This
   solution is necessary to support routing of mid-dialog requests while
   preserving Edge Proxy failover within an outbound-proxy-set.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terms and Definitions  . . . . . . . . . . . . . . . . . . . .  4
   3.  Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Solution Requirements  . . . . . . . . . . . . . . . . . . . .  8
   5.  Proposed Solution  . . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  User Agent Proceedures . . . . . . . . . . . . . . . . . .  9
     5.2.  Edge Proxy Proceedures . . . . . . . . . . . . . . . . . .  9
       5.2.1.  Processing REGISTER Requests . . . . . . . . . . . . .  9
       5.2.2.  Record-Routing Dialog Forming Requests . . . . . . . .  9
       5.2.3.  Forwarding Dialog Forming and Mid-Dialog Requests  . . 10
     5.3.  Registrar/Authoritative Proxy  . . . . . . . . . . . . . . 10
       5.3.1.  Processing REGISTER Requests . . . . . . . . . . . . . 10
       5.3.2.  Record-Routing Dialog Forming Requests . . . . . . . . 11
       5.3.3.  Forwarding Mid-Dialog Requests . . . . . . . . . . . . 11
     5.4.  Limitations  . . . . . . . . . . . . . . . . . . . . . . . 11
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   9.  Changes  . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     9.1.  changes from 01 Version  . . . . . . . . . . . . . . . . . 15
     9.2.  changes from 00 Version  . . . . . . . . . . . . . . . . . 15
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
     10.2. Informative References . . . . . . . . . . . . . . . . . . 16
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18













Johns                    Expires August 4, 2007                 [Page 2]

Internet-Draft         Mid dialog request routing           January 2007


1.  Introduction

   The Internet Draft titled Managing Client Initiated Connections in
   the Session Initiation Protocol [OUTBOUND] describes extensions to
   the Session Initiation Protocol (SIP) to support NAT traversal.  In
   particular it defines behaviors for User Agents, registrars and proxy
   servers that allow dialog initiating requests to be delivered on
   existing flows established by the User Agent at Registration time.
   However, procedures for the routing of mid-dialog request over an
   existing flow is explicitly placed out of scope by [OUTBOUND].

   This draft highlights some of the issues that may arise due to the
   lack of guidance on how to route mid-dialog requests in [OUTBOUND]
   and attempts to present a solution based on existing procedures in
   [OUTBOUND].




































Johns                    Expires August 4, 2007                 [Page 3]

Internet-Draft         Mid dialog request routing           January 2007


2.  Terms and Definitions

   Note: The following definitions are borrowed from [OUTBOUND]

   Authoritative Proxy: A proxy that handles non-REGISTER requests for a
   specific Address-of-Record (AOR), performs the logical Location
   Server lookup described in RFC 3261, and forwards those requests to
   specific contact URIs.

   Edge Proxy: An Edge Proxy is any proxy that is located topologically
   between the registering SIP User Agent (SIP UA) and the registrar.

   Flow: A Flow is a network protocol layer (layer 4) association
   between two hosts that is represented by the network address and port
   number of both ends and by the protocol.  For TCP, a flow is
   equivalent to a TCP connection.  For UDP a flow is a bidirectional
   stream of datagrams between a single pair of IP addresses and ports
   of both peers.  With TCP, a flow often has a one to one
   correspondence with a single file descriptor in the operating system.

   Instance-id: This specification uses the word instance-id to refer to
   the value of the "sip.instance" media feature tag in the Contact
   header field.  This is a Uniform Resource Name (URN) that uniquely
   identifies this specific UA instance.

   Outbound-proxy-set: A set of SIP URIs (Uniform Resource Identifiers)
   that represents each of the outbound proxies (often Edge Proxies)
   with which the UA will attempt to maintain a direct flow.  The first
   URI in the set is often refereed to as the primary outbound proxy and
   the second as the secondary outbound proxy.  There is no difference
   between any of the URIs in this set, nor does the primary/secondary
   terminology imply that one is preferred over the other.

   Note: The following definition is added by this document

   Stream-id: (This needs a better name) An identifier created by the
   registrar which identifies a set of flows between the Registrar and
   all Edge Proxies the UA has registered through.













Johns                    Expires August 4, 2007                 [Page 4]

Internet-Draft         Mid dialog request routing           January 2007


3.  Use Case

   Section 5.3 of [OUTBOUND] states: "Note that techniques to ensure
   that mid-dialog requests are routed over an existing flow are out of
   scope and therefore not part of this specification.  However, an
   approach such as having the Edge Proxy Record-Route with a flow token
   is one way to ensure that mid-dialog requests are routed over the
   correct flow."

   Consider the following network architecture as presented in
   [OUTBOUND]in figure 1 below.



                   +---------+
                   |Registrar|
                   |Proxy    |
                   +---------+
                    /      \
                   /        \
                  /          \
               +-----+     +-----+
               |Edge1|     |Edge2|
               +-----+     +-----+
                  \           /
                   \         /
           ----------------------------NAT/FW
                     \     /
                      \   /
                     +------+
                     |User  |
                     |Agent |
                     +------+



   Figure 1: Example network architecture

   In this scenario the User Agent is configured with an outbound-proxy-
   set that consists of "sip:edge1.example.com;lr;keepalive=stun" and
   "sip:edge2.example.com;lr;keepalive=stun" and has registered through
   each.

   A session is established through the primary edge proxy which follows
   the suggestion in outbound to include a flow token in the Record-
   Route entry.  Should the primary edge proxy fail mid-call, the User
   Agents will not be affected by this failure until the session is
   cleared.  Please see figure 2 below for an illustration of this



Johns                    Expires August 4, 2007                 [Page 5]

Internet-Draft         Mid dialog request routing           January 2007


   scenario.



          Callee             Edge2             Edge1            Caller
             |                 |                 |                 |
             |                 |                 |                 |
             |                 |                 |                 |
             |                 |                 |(1) INVITE       |
             |                 |                 |<----------------|
             |                 |                 |Edge1 record routes
             |                 |                 |                 |
             |                 |                 |INVITE with Flow Token
             |                 |                 |                 |
             |(2) INVITE       |                 |                 |
             |<----------------------------------|                 |
             |(3) 180 Ringing  |                 |                 |
             |---------------------------------->|                 |
             |                 |                 |(4) 180 Ringing  |
             |                 |                 |---------------->|
             |(5) 200 OK       |                 |                 |
             |---------------------------------->|                 |
             |                 |                 |(6) 200 OK       |
             |                 |                 |---------------->|
             |                 |                 |(7) ACK          |
             |                 |                 |<----------------|
             |(8) ACK          |                 |                 |
             |<----------------------------------|                 |
             |                 |                 X - Crash         |
             |                 |                                   |
             |(9) BYE          |                                   |
             |----------------------------------> No response      |
             |                 |                                   |
             |                 |                                   |
             |(10) BYE         |                                   |
             |---------------->|                                   |
             |                 |How does the Callee determine      |
             |                 |                                   |
             |                 |it shoud now send the BYE          |
             |                 |                                   |
             |                 |to Edge2?                          |
             |                 |                                   |
             |                 |                                   |
             |                 |                                   |



   Figure 2: Routing of Mid-Dialog Requests



Johns                    Expires August 4, 2007                 [Page 6]

Internet-Draft         Mid dialog request routing           January 2007


   Message 1 is a normal INVITE with the exception that Edge1 adds a
   Record-Route header with a flow token.

   Record-Route:
   <sip:PQPbqQE+Ynf+tzRPD27lU6uxkjQ8LLUG@proxy-set.example.com;>

   In message 9, the BYE is sent to Edge1 per the route set.  Given that
   Edge1 has failed it will not respond to the BYE reqeust from the
   caller.  As previously stated, [OUTBOUND] does not discuss how the
   caller determines it should send the BYE request to Edge2.  As such
   this document discusses two issues related to following the
   suggestion in [OUTBOUND] for routing of mid-dialog requests:

   1.  How to route to Edge2 when Edge1 has failed and added a Record-
       Route entry when the dialog was established.

   2.  How does Edge2 determine which flow to forward a mid-dialog
       request on if the dialog was established via Edge1.

































Johns                    Expires August 4, 2007                 [Page 7]

Internet-Draft         Mid dialog request routing           January 2007


4.  Solution Requirements

   Before presenting a solution it is useful to present the requirements
   a solution must satisfy.  As such, any solution that attempts to
   solve this use case should adhere to the following requirements:

   1.  The flow token is unique to a flow, the flow can be recovered
       from the token, and the token can not be modified by attackers
       (this requirement is taken from [OUTBOUND]);

   2.  work in the presence of multiple Edge Proxies supporting
       redundant flows to the registrar;

   3.  support the use case identified in this document for the routing
       of mid-dialog requests;

   4.  work for the case where the SIP UA registers multiple AORs from
       the same contact or different contact.

   5.  ensure that if a edge proxy inserted a URI into a Record-Route
       header field, that it should continue to see that URI in the
       Route header field of mid-dialog request, even if the mid-dialog
       request is sent to a backup edge proxy;

   6.  not require that edge proxies have to replicate any kind of
       dynamic state between them;

   7.  not require the SIP UA to register through all edge proxies
       served by a given Registrar/Authoritative Proxy.






















Johns                    Expires August 4, 2007                 [Page 8]

Internet-Draft         Mid dialog request routing           January 2007


5.  Proposed Solution

   The following sections propose a solution which satisfies the
   majority of the above requirements.  In summary the solution relies
   on each Edge Proxy adding a Record-Route entry to each dialog
   establishing request.  The entry contains a flow token as suggested
   by outbound.  However, the flow token used is the sip.instance value
   provided in the original REGISTER request.  This ensures that any
   Edge Proxy the UA may have registered through, would understand the
   flow token and be able to forward the Request properly.  The solution
   also requires the Register to remember which edge proxies a UA
   registers through.  This is facilitated by have the registrar
   associate each REGISTER for the same sip.instance with a stream-id.
   The stream-id in turn identifies which edge proxies were used for the
   REGISTER request.  The Registrar returns this stream-id in the
   Service-Route header for each successful REGISTER request.  The UA
   includes the received service-route information in its dialog forming
   request.  This forces all dialog forming requests through the
   Registrar which allows the Registrar to add a Record-Route entry with
   the stream-id.  Should the edge proxy which the dialog was
   established through fail, the Registrar can easily route to the next
   edge proxy identified by the stream-id in the resulting Route set.

5.1.  User Agent Proceedures

   This document imposes no new requirements on the user agent other
   then those already specified by [OUTBOUND].

5.2.  Edge Proxy Proceedures

5.2.1.  Processing REGISTER Requests

   This document imposes no new requirement on the Edge Proxy for
   processing Initial REGISTER or Re-REGISTER requests other then those
   already defined by [OUTBOUND].

5.2.2.  Record-Routing Dialog Forming Requests

   If the request is a dialog forming request, an edge proxy MUST
   record-route.  The edge proxy MUST insert a flow token in the user
   portion of the URI.  The edge proxy MUST use the SIP UA provided
   instance-id in the contact header of the REGISTER request as the flow
   token.

   However, this does not protect the flow token from modification by
   attackers.  To protect against modification by attackers the flow
   token should be generated as follows: The Edge Proxy (both Primary
   and Secondary are configured with the same random 20 byte key called



Johns                    Expires August 4, 2007                 [Page 9]

Internet-Draft         Mid dialog request routing           January 2007


   K. The HMAC of the SIP UA provided instance-id is computed using the
   key K and the HMAC-SHA1-80 algorithm, as defined in [RFC2104].  The
   concatenation of the HMAC and instance-id are base64 encoded, as
   defined in [RFC3548], and used as the flow identifier.

   The requirement that the flow be recoverable from the token cannot be
   satisfied if Edge Proxy failover is desired as the flow itself is
   specific to the Edge Proxy and cannot be generalized.

5.2.3.  Forwarding Dialog Forming and Mid-Dialog Requests

   There are no changes to how the Edge Proxy forwards requests.  The
   Edge Proxy can verify that the flow token has not been tampered by
   verifying the instance-id in the user part of the route header by
   calculating the HMAC and comparing to the HMAC in the flow token, if
   they match the instance-id can be considered valid and the request
   forwarded on the proper flow.

   To cover the case where an Edge Proxy may have crashed and since
   recovered but lost its dialog state information (and associated
   flows), it is important that should the Edge Proxy receive a mid-
   dialog request which contains a flow token which it does not
   understand, it return a 430 response as defined by outbound.

5.3.  Registrar/Authoritative Proxy

5.3.1.  Processing REGISTER Requests

   Upon receipt of a REGISTER Request, the Registrar first checks to see
   if it contains a sip.instance indicator in the Contact header.  If no
   such indicator is present, then the Registrar continues to process
   the REGISTER per RFC 3261.

   If the REGISTER contains the sip.instance indicator, the Registrar
   retrieves the sip.instance value and searches for an existing
   registration with the same value.  If no match is found, this is an
   initial Registration attempt by that specific client instance.  If
   the registration attempt is successful, the Registrar creates a
   stream-id and associates the tuple the REGISTER was received on with
   it.  It MUST include a Service-Route header in response to the
   REGISTER Request.  The Service-Route header MUST contain the
   stream-id in the user portion of the URI inserted in the Service-
   Route header.

   If the Registrar finds an existing Registration for the same
   sip.instance value, this is either a Re-Registration or a new
   Registration through a different Edge Proxy.  In this case, if the
   REGISTER Request is successful, the Registrar adds the tuple the



Johns                    Expires August 4, 2007                [Page 10]

Internet-Draft         Mid dialog request routing           January 2007


   REGISTER was received on to the list of tuples associated with the
   stream-id.  It MUST include a Service-Route header in response to the
   REGISTER Request.  The Service-Route header MUST contain the
   stream-id in the user portion of the URI inserted in the Service-
   Route header.

5.3.2.  Record-Routing Dialog Forming Requests

   When a dialog is created the UA will place the received Service-Route
   header in the Route header.  When the registrar receives the dialog
   request, the route header will identify the set of flows which the UA
   has registered through (the different edge proxies which the UA has
   registered through).  The registrar MUST add a record-route entry
   with the user part being the stream-id along with extra information
   identifying which of the flows the dialog was established via.
   [TODO: Need to work out exactly how this will be done, as part of the
   user part Reg-id+stream-id, as a separate opaque parameter flow-id=x,
   or in some other way.]

5.3.3.  Forwarding Mid-Dialog Requests

   When the registrar receives a mid-dialog request, it uses the
   stream-id which is located in the user portion of its Route header
   entry to forward the Request.  If the edge proxy which established
   the dialog is no longer available, the Registrar MUST forward the
   request to the next Edge Proxy identified by the stream-id.

5.4.  Limitations

   As stated above the use of the instance ID does not allow the flow to
   be recovered from the flow token.

   Additionally if a SIP UA is registering multiple AORs, this solution
   would require they all be registered over the same flow as they will
   all be registered using the same instance ID.  If the SIP UA wanted
   to register multiple AORs against different contacts, it would
   require a different instance ID for each contact.














Johns                    Expires August 4, 2007                [Page 11]

Internet-Draft         Mid dialog request routing           January 2007


6.  IANA Considerations

   There are no IANA Considerations
















































Johns                    Expires August 4, 2007                [Page 12]

Internet-Draft         Mid dialog request routing           January 2007


7.  Security Considerations

   Outbound does not contemplate the idea of the flow token being known
   by the client.  The solution proposed in this document relies on the
   Edge Proxy populating the record-route header with not only its URI
   but the flow token associated with the client it is providing service
   to.  The end result is that the remote client will now know flow
   token.  It is unclear what benefit this provides the remote client.
   For unchanged Outbound procedures, the threats listed in [OUTBOUND]
   are also applicable to this document.









































Johns                    Expires August 4, 2007                [Page 13]

Internet-Draft         Mid dialog request routing           January 2007


8.  Acknowledgements

   The author would like to thank the following individuals for their
   feedback, comments and recommendations (in alphabetical order):
   Cullen Jennings, David Hancock and Jean-Francois Mule.














































Johns                    Expires August 4, 2007                [Page 14]

Internet-Draft         Mid dialog request routing           January 2007


9.  Changes

   Note to RFC Editor: Please remove this entire section.

9.1.  changes from 01 Version

   Added proceedures for the Registrar to determine which edge proxy to
   forward a mid-dialog request to should the edge proxy which
   established the dialog fail.  Significant rework of the requirements
   and problem statement was also done.

9.2.  changes from 00 Version

   Updated the figure to better illustrate the use case.  Removed the
   sections after the figure as they were no longer relvant.  Expaned
   text in section 5 intro.



































Johns                    Expires August 4, 2007                [Page 15]

Internet-Draft         Mid dialog request routing           January 2007


10.  References

10.1.  Normative References

   [OUTBOUND]
              Jennings, C. and R. Mahy, "Managing Client Initiated
              Connections in the Session Initiation Protocol(SIP)",
              March 2006.

10.2.  Informative References

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

   [RFC3548]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 3548, July 2003.


































Johns                    Expires August 4, 2007                [Page 16]

Internet-Draft         Mid dialog request routing           January 2007


Author's Address

   Kevin Johns
   CableLabs
   858 Coal Creek Circle
   Louisville, CO  80027
   USA

   Email: k.johns@cablelabs.com










































Johns                    Expires August 4, 2007                [Page 17]

Internet-Draft         Mid dialog request routing           January 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).





Johns                    Expires August 4, 2007                [Page 18]