SIP K. Johns Internet-Draft CableLabs Intended status: Standards Track October 22, 2006 Expires: April 25, 2007 Routing of mid dialog requests using sip-outbound draft-johns-sip-outbound-middialog-draft-01 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 April 25, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Johns Expires April 25, 2007 [Page 1] Internet-Draft Mid dialog request routing October 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 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. 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. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. changes from 00 Version . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Johns Expires April 25, 2007 [Page 2] Internet-Draft Mid dialog request routing October 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, 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 April 25, 2007 [Page 3] Internet-Draft Mid dialog request routing October 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) 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. Johns Expires April 25, 2007 [Page 4] Internet-Draft Mid dialog request routing October 2006 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." Routing of mid-dialog requests in the presence of NATs is a critical aspect of any comprehensive NAT traversal solution. To illustrate this point the following use case is presented. Consider the case where a session is established through the primary proxy which follows the suggestion in outbound to include a flow token in the Record-Route entry. Should the primary proxy fail mid-call, the User Agents will not be affected by this failure until the session is cleared. Please see figure 1 below for an illustration of this use case. Johns Expires April 25, 2007 [Page 5] Internet-Draft Mid dialog request routing October 2006 [-----example.com domain -------------------] Callee Secondary Primary Caller | | | | | | | | | | | | | | |(1) INVITE | | | |<----------------| | | |Primary record routes | | | | | | |INVITE with Flow Token | | | | | | |URI resolves to both | | | | | | |Primary and Secondary | | | | |(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 | | | |---------------->| | | | |Secondary does not understand | | | | | | |flow token and cannot deliver | | | | | | | | | | | | | Figure 1: Routing of Mid-Dialog Requests Johns Expires April 25, 2007 [Page 6] Internet-Draft Mid dialog request routing October 2006 This call flow assumes that the Caller 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" and has registered through each. Message 1 is a normal INVITE with the exception that the primary proxy adds a Record-Route header with a flow token. Record-Route: <sip:PQPbqQE+Ynf+tzRPD27lU6uxkjQ8LLUG@proxy-set.example.com;lr> In message 9, the BYE is sent to the primary proxy per the route set. Given that the primary proxy 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 the secondary proxy. 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 a secondary proxy when the primary proxy has added a Record-Route entry 2. How does the secondary proxy determine which flow to forward a mid-dialog request on if the dialog was established via the primary proxy. Johns Expires April 25, 2007 [Page 7] Internet-Draft Mid dialog request routing October 2006 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. Johns Expires April 25, 2007 [Page 8] Internet-Draft Mid dialog request routing October 2006 5. Proposed Solution The following sections propose a solution which satisfies the majority of the above requirements and make the following assumption: The edge proxy adds a Record-Route entry to each dialog initiating request. The entry contains a SIP URI which is comprised of a flow token and a domain name. The domain name entered resolves to both the primary and secondary proxies. 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. Johns Expires April 25, 2007 [Page 9] Internet-Draft Mid dialog request routing October 2006 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 April 25, 2007 [Page 10] Internet-Draft Mid dialog request routing October 2006 6. IANA Considerations There are no IANA Considerations Johns Expires April 25, 2007 [Page 11] Internet-Draft Mid dialog request routing October 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 April 25, 2007 [Page 12] Internet-Draft Mid dialog request routing October 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 April 25, 2007 [Page 13] Internet-Draft Mid dialog request routing October 2006 9. Changes Note to RFC Editor: Please remove this entire section. 9.1. 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 April 25, 2007 [Page 14] Internet-Draft Mid dialog request routing October 2006 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 April 25, 2007 [Page 15] Internet-Draft Mid dialog request routing October 2006 Author's Address Kevin Johns CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA Email: k.johns@cablelabs.com Johns Expires April 25, 2007 [Page 16] Internet-Draft Mid dialog request routing October 2006 Full 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. 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. 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 April 25, 2007 [Page 17]