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]