One document matched: draft-johns-sip-outbound-middialog-draft-00.txt
SIP K. Johns
Internet-Draft CableLabs
Expires: December 19, 2006 June 17, 2006
Routing of mid dialog requests using sip-outbound
draft-johns-sip-outbound-middialog-draft-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 December 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes modifications to the procedures for the
generation of a flow token as described in the Internet Draft titled
Managing Client Initiated Connections in the Session Initiation
Protocol. This modification is necessary to support routing of mid-
dialog requests while preserving Edge Proxy failover.
Johns Expires December 19, 2006 [Page 1]
Internet-Draft Mid dialog request routing June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4
3. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Use of Record-Route without a Flow Token . . . . . . . . . 7
3.2. Use of Record-Route with a Flow Token . . . . . . . . . . 7
4. Solution Requirements . . . . . . . . . . . . . . . . . . . . 8
5. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Edge Proxy Procedures . . . . . . . . . . . . . . . . . . 9
5.1.1. Generating Flow Tokens . . . . . . . . . . . . . . . . 9
5.1.2. Forwarding Requests . . . . . . . . . . . . . . . . . 9
5.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Johns Expires December 19, 2006 [Page 2]
Internet-Draft Mid dialog request routing June 2006
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. However, routing of
mid-dialog request over an existing flow is explicitly placed out of
scope by [OUTBOUND].
This draft is an attempt to highlight some of the issues that may
arise due to the lack of definition of how to route mid-dialog
requests in [OUTBOUND] and attempts to present a solution based on
existing procedures defined in [OUTBOUND].
Johns Expires December 19, 2006 [Page 3]
Internet-Draft Mid dialog request routing June 2006
2. Terms and Definitions
Note: The following definitions are borrowed from [OUTBOUND]
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 of the OSI model)
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 SIP UA instance.
Outbound-proxy-set: A configured set of SIP URIs (Uniform Resource
Identifiers) that represents each of the outbound proxies (often Edge
Proxies) with which the SIP UA will attempt to maintain a direct
flow.
Johns Expires December 19, 2006 [Page 4]
Internet-Draft Mid dialog request routing June 2006
3. Use Case
According to section 5.3 of [OUTBOUND]: 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.
The following use case, as taken from [OUTBOUND], illustrates how
mid-dialog requests can be routed. However, this use case does not
cover how the caller determines that it should use the backup Edge
Proxy.
Johns Expires December 19, 2006 [Page 5]
Internet-Draft Mid dialog request routing June 2006
[-----example.com domain -------------------]
Caller Backup Primary Callee
| | | (1) REGISTER |
| | |<-----------------|
| | |(2) 200 OK |
| | |----------------->|
| | | (3) REGISTER |
| |<------------------------------------|
| |(4) 200 OK | |
| |------------------------------------>|
|(5) INVITE | | |
|----------------------------------->| |
| | |(6) INVITE |
| | |----------------->|
| | | (7) 200 OK |
| | |<-----------------|
| | (8) 200 OK | |
|<-----------------------------------| |
|(9) ACK | | |
|----------------------------------->| |
| | |(10) ACK |
| | |----------------->|
| | CRASH X |
|(11) BYE | |
|---------------->| |
| | (12) BYE |
| |------------------------------------>|
| | (13) 200 OK |
| |<------------------------------------|
| (14) 200 OK | |
|<----------------| |
Figure 1: Routing of Mid-Dialog Requests
This call flow assumes that the Callee has been configured with a
outbound proxy set that consists of "sip:primary.example.com;lr;sip-
stun" and "sip:backup.example.com;lr;sip-stun".
Messages 1-5 are as defined in [OUTBOUND]. The INVITE in message 6
is a normal INVITE except that the Primary Edge Proxy has Record-
Routed. As a result 6 will have a: Record-Route: <sip:
edgeproxyset1.example.com;lr>
In message 11, the BYE is sent to the backup Edge Proxy after the
primary Edge Proxy failed to respond. How this is accomplished is
the focus of this document.
Johns Expires December 19, 2006 [Page 6]
Internet-Draft Mid dialog request routing June 2006
3.1. Use of Record-Route without a Flow Token
Given that the primary Edge Proxy added a Record-Route header during
the dialog establishment, the BYE must follow the established route
set. It is possible that the URI in the route set could resolve to
multiple IP addresses and thus identify both the primary and backup
Edge Proxies. Assuming this to be the case, the caller would first
send the BYE to the primary Edge Proxy and after a period of no
response, send the BYE to the backup Edge Proxy.
Upon receipt of the BYE, the backup Edge Proxy will attempt to
forward the BYE based on the request URI as the route header will not
identify a specific flow. The request URI identifies the callee
based on the provided contact address. If the callee is behind a NAT
device, the contact address will most likely be an IP Address
containing the callees locally assigned IP Address. Since this
address will not be routable by the Edge Proxy, the BYE will result
in an error being returned to the caller.
3.2. Use of Record-Route with a Flow Token
If in message 6, the primary Edge Proxy Record-Routes and includes a
flow token, message 6 will have a: Record-Route: <sip:
edgeproxyset1.example.com;lr;user=flowtoken>
Where the name edgeproxyset1.example.com resolves to the primary and
backup Edge Proxies.
Again the BYE must follow the established route set and again the
caller would first send the BYE to the primary Edge Proxy and after a
period of no response, send the BYE to the backup Edge Proxy.
Upon receipt of the BYE, the backup Edge Proxy will attempt to
forward the BYE based on the flow token in the route header rather
then the request URI. Given that this flow token was generated by
the primary Edge Proxy, the backup will have no knowledge of such a
flow and not be able to route the BYE resulting in an error being
returned to the caller.
Johns Expires December 19, 2006 [Page 7]
Internet-Draft Mid dialog request routing June 2006
4. Solution Requirements
Any solution that attempts to solve these use cases 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.
Johns Expires December 19, 2006 [Page 8]
Internet-Draft Mid dialog request routing June 2006
5. Proposed Solution
The following sections propose a solution where a flow token is
generated which has meaning to any Edge Proxy for which the SIP UA
has a valid flow established with. This token is then used by the
Edge Proxy to record route itself during the dialog establishment.
5.1. Edge Proxy Procedures
5.1.1. Generating Flow Tokens
Outbound states a proxy can use any algorithm it wants as long as 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.
The use of the SIP UA provided instance-id in the contact header of
the REGISTER request satisfies the first desired characteristic.
However, it does not allow the flow to be recovered from the token
nor does it protect the 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 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.1.2. Forwarding 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.
5.2. 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
Johns Expires December 19, 2006 [Page 9]
Internet-Draft Mid dialog request routing June 2006
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 December 19, 2006 [Page 10]
Internet-Draft Mid dialog request routing June 2006
6. IANA Considerations
There are no IANA Considerations
Johns Expires December 19, 2006 [Page 11]
Internet-Draft Mid dialog request routing June 2006
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 December 19, 2006 [Page 12]
Internet-Draft Mid dialog request routing June 2006
8. Acknowledgements
The author would like to thank the following individuals for their
feedback, comments and recommendations (in alphabetical order):
Cullen Jennings and Jean-Francois Mule.
Johns Expires December 19, 2006 [Page 13]
Internet-Draft Mid dialog request routing June 2006
9. References
9.1. Normative References
[OUTBOUND]
Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol(SIP)",
March 2006.
9.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 December 19, 2006 [Page 14]
Internet-Draft Mid dialog request routing June 2006
Author's Address
Kevin Johns
CableLabs
858 Coal Creek Circle
Louisville, CO 80027
USA
Email: k.johns@cablelabs.com
Johns Expires December 19, 2006 [Page 15]
Internet-Draft Mid dialog request routing June 2006
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 (2006). 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.
Johns Expires December 19, 2006 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-21 22:35:52 |