SIP E. Koivusalo Internet-Draft Nokia Expires: October 21, 2006 April 19, 2006 Discovering Proxies Supporting SIP Outbound draft-koivusalo-sip-outbound-discovery-00.xml 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 October 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes modifications to DNS procedures used to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. These modifications enable the SIP User Agent to discover those proxies, within the domain of the SIP URI, that support SIP extensions described in draft-ietf-sip-outbound document. The introduced mechanisms update behavior defined in RFC 3263. Koivusalo Expires October 21, 2006 [Page 1] Internet-Draft Proxy Discovery for SIP Outbound April 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview of Problems and Solutions . . . . . . . . . . . . . . 4 2.1. Discovering Proxies Supporting SIP Outbound . . . . . . . 4 2.2. Discovering Primary and Backup Proxies . . . . . . . . . . 4 2.3. Benefits and Drawbacks on using DNS . . . . . . . . . . . 5 2.4. Comparison to Other Solutions . . . . . . . . . . . . . . 6 3. Conventions and Terminology . . . . . . . . . . . . . . . . . 8 4. New NAPTR Service types . . . . . . . . . . . . . . . . . . . 9 5. User Agent Mechanisms . . . . . . . . . . . . . . . . . . . . 10 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Koivusalo Expires October 21, 2006 [Page 2] Internet-Draft Proxy Discovery for SIP Outbound April 2006 1. Introduction Document draft-ietf-sip-outbound [8] describes extensions to Session Initiation Protocol (SIP), which enable the User Agent (UA) to create and maintain a persistent flow towards a Proxy, so that the Proxy is able to use the existing flow for routing messages towards the UA. In this document those extensions are referred as 'SIP Outbound'. These extensions are not backwards compatible for proxies compliant to RFC3261 [3] as they, for instance, require the proxy to support Simple Traversal of UDP through NATs (STUN) protocol for flow keepalive messages in the same port that the proxy uses for SIP. RFC 3263 [2] describes DNS procedures used to locate SIP servers. This document describes the specific problems that a UA meets with when locating SIP proxies supporting SIP Outbound. It also provides a solution, based on DNS NAPTR (Naming Authority Pointer) and SRV (Location of Service) records, along with a discussion about the benefits and drawbacks of this solution in comparison to known alternatives. The outlined solution updates the procedures described in RFC 3263 [2] and RFC 2782 (DNS SRV). [5]. Koivusalo Expires October 21, 2006 [Page 3] Internet-Draft Proxy Discovery for SIP Outbound April 2006 2. Overview of Problems and Solutions SIP service providers may divide their proxies to multiple farms: o Primary proxies supporting the extensions defined in draft-ietf-sip-outbound [8] so that the clients of the service provider can use those servers as their primary outbound proxies. o Backup proxies supporting SIP Outbound extensions so that the clients of the service provider can use those servers as their backup outbound proxies, as suggested in draft-ietf-sip-outbound [8]. Note that the service provider could use the second set of proxies also for load balancing reasons. o Proxies not supporting SIP Outbound extensions, to be used by clients of other service providers when trying to reach the SIP users registered into the domain of the service provider. This kind of setup poses the UA with two problems when it tries to locate an outbound proxy to use: Which proxies in the domain support SIP Outbound ? Which proxies in the domain should be used for the primary flow and which ones for the backup flow ? 2.1. Discovering Proxies Supporting SIP Outbound For an UA located behind a NAT or firewall it is important to be able to find those proxies within the domain, that support the SIP Outbound extensions. The UA needs the proxy to support SIP Outbound to be able to form a flow through the middlebox and keep it alive by sending STUN Binding Requests to the Proxy. The solution to this problem is to introduce new values for service field of NAPTR record to be used for proxies supporting SIP Outbound. When performing a NAPTR query for the domain name, the UA looking for SIP Outbound support would pick those NAPTR records indicating the related service type. 2.2. Discovering Primary and Backup Proxies There should be a mechanism for the UA to find out which of the proxies within the domain should be used for forming the primary flow and which ones for forming the backup flows. RFC 3263 [2] describes the possibility of configuring SRV records for primary and backup proxies as follows: Koivusalo Expires October 21, 2006 [Page 4] Internet-Draft Proxy Discovery for SIP Outbound April 2006 "The SRV records for a particular target can be set up so that there is a single record with a low value for the priority field (indicating the preferred choice), and this record points to the specific element that constructed the URI. However, there are additional records with higher values of the priority field that point to backup elements that would be used in the event of failure. This allows the constraint of RFC 3261 [1] to be met while allowing for robust operation." The solution to this problem is to take an advantage of the SRV priority field and introduce a change to DNS SRV record processing as described in RFC 2782 [5] as follows: "A client MUST attempt to contact the target host with the lowest- numbered priority it can reach." The idea is that the UA would create the primary flow towards the target host with the lowest-numbered priority it can reach and a separate backup flow towards a single target host for each priority level having a higher number. UA should use the SRV records in this way when the SRV records were found as a result of NATPR query for SIP Outbound service. 2.3. Benefits and Drawbacks on using DNS DNS-based discovery of proxies to be used for SIP Outbound help the service provider to deploy UAs supporting those extensions without extra configuration effort. Using the DNS procedures outlined in this document provides the following benefits: o Using DNS enables the UA to specifically select the proxies supporting SIP Outbound, instead of only blindly trying whether any of the resolved proxies would support it. o DNS tells the UA whether the proxy supports SIP Outbound or not even before starting to communicate the proxy and avoids the extra transactions caused by the proxy rejecting or redirecting the REGISTER request. o DNS also supports the case where domain name of the proxy is discovered by Dynamic Host Configuration Protocol (DHCP). As DHCP SIP Server option returns proxy domain names without port or transport, it causes the UA compliant to RFC 3263 [2] to make a NAPTR query for that domain. o Additional NAPTR records do not introduce backwards compatibility problems for UAs not supporting SIP Outbound, since those UAs would discard those new NAPTR service types according to RFC 3263 Koivusalo Expires October 21, 2006 [Page 5] Internet-Draft Proxy Discovery for SIP Outbound April 2006 rules. o No new SRV records would be needed if the same proxy can be used with or without SIP Outbound. In this case the new NAPTR records would be mapped to the very same SRV RRs that would be used for existing "SIPS+D2T", "SIP+D2T", "SIP+D2U", "SIPS+D2S" and "SIP+ D2S" services. Introducing new NAPTR records for SIP Outbound will actually double the number of NAPTR records needed for SIP service. Currently five NAPTR service types have been defined for SIP. There is one service type for each transport protocol: UDP, TCP with and without TLS (Transport Layer Security) and SCTP (Stream Control Transmission Protocol) also with and without TLS [1]. Defining new NAPTR service types for protocols that UA uses to connect proxies with SIP Outbound support results five new NAPTR services. Using DNS in this way is not scalable as discussed in RFC 3486 [9]. However using DNS in the context of SIP Outbound is justified because the UA does not only need to know if the discovered proxy supports the needed extensions or not, but it specifically needs to locate such proxies that do support those extensions for NAT traversal. 2.4. Comparison to Other Solutions If an UA does not implement the extensions to DNS procedures as described in this document, it can locate the proxy with the conventional SIP proxy discovery procedure as described in RFC3263 [2]. After locating a proxy the UA can compose a REGISTER request and send it towards the discovered proxy. If the proxy does not support the required extensions it can reject the request or redirect the UA to try another proxy. Drawbacks of this solution are as follows: o There is at least one extra round-trip for redirection if the discovered proxy did not support SIP Outbound. If the proxy does not redirect but instead rejects the REGISTER, then the UA can only blindly try the next proxy returned by DNS. o There is no way for the UA to automatically find backup proxies towards which a backup flow could be formed. UA could be configured with different domain names of the primary and backup proxy, but this solution would not apply in the case where UA finds the proxy by DHCP SIP Server option. Further on, if no DNS services are standardized for SIP Outbound, service providers might use various methods to differentiate their proxy farms. These techniques could use proprietary types of DNS SRV records or different domain names for different farms. In all cases Koivusalo Expires October 21, 2006 [Page 6] Internet-Draft Proxy Discovery for SIP Outbound April 2006 the UA would need some extra configuration information to find out how DNS has been set up and how it should be used when locating outbound proxies. Koivusalo Expires October 21, 2006 [Page 7] Internet-Draft Proxy Discovery for SIP Outbound April 2006 3. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [7]. Koivusalo Expires October 21, 2006 [Page 8] Internet-Draft Proxy Discovery for SIP Outbound April 2006 4. New NAPTR Service types The values for NAPTR service field indicating a proxy supporting SIP Outbound are "SIP-O+D2U", "SIP-O+D2T", "SIPS-O+D2T", "SIP-O+D2S" and "SIPS-O+D2S". The value "SIP-O" or "SIPS-O" in the service_field of NAPTR record will indicate proxies supporting SIP Outbound, while the rs field indicates supported transport protocols using values as defined in RFC 3263 [2]. This document establishes a new IANA registry for those NATPR service names. NAPTR records using those new service types MUST provide a mapping from a domain to the SRV record. The corresponding SRV records MUST indicate SIP servers supporting SIP Outbound and the specific transport protocol in the NAPTR services field. [[Open question: Is there a strong need for UAs to be able to use SCTP ? UAs typically support UDP, TCP and TLS but not SCTP. Is it worth introducing two new NAPTR service types like "SIP-O+D2S" and "SIPS-O+D2S" for SCTP ?]] Koivusalo Expires October 21, 2006 [Page 9] Internet-Draft Proxy Discovery for SIP Outbound April 2006 5. User Agent Mechanisms The procedures here are invoked when a UA needs to send a request via a proxy supporting SIP Outbound and has a SIP or SIPS (secure SIP) URI of the proxy without port, transport or maddr parameters as the next hop. According to RFC 3263 [2] the UA "SHOULD perform a NAPTR query for the domain in the URI." This specification assumes the UA would proceed to perform the NAPTR query and related SRV queries as specified in RFC 3263, but with the exceptions defined in this specification. In this specification we assume that UA is interested on proxies supporting SIP Outbound. UAs conforming this specification MUST apply the following rules for processing NATPR and SRV queries: As per RFC 2915 [4], the client discards any NAPTR records whose services fields are not applicable. A client resolving a SIPS URI MUST discard any services that do not contain "SIPS-O" as the protocol in the service field. A client resolving a SIP URI MUST retain records with "SIP-O" and the transport protocols the client supports and SHOULD retain records with "SIPS-O", if the client supports TLS. Section "Usage rules" of RFC 2782 [5] describe how to sort SRV records and select the most preferred one amongst those. For the purpose of the UA discovering multiple proxies for sending a REGISTER and forming a flow to each of them, the procedure SHOULD be modified as follows: For each distinct priority level Create a new empty list While there are still elements left at this priority level Select an element as specified above, in the description of Weight in "The format of the SRV RR" Section, and move it to the tail of the new list For each element in the new list query the DNS for address records for the Target or use any such records found in the Additional Data section of the earlier SRV response. for each address record found, try to connect to the Koivusalo Expires October 21, 2006 [Page 10] Internet-Draft Proxy Discovery for SIP Outbound April 2006 (protocol, address, service). In other words, instead of just connecting to one single proxy preferred by the combination of priority and weight fields, the UA SHOULD connect to one proxy on each priority level, as preferred by the weight field. When performing NAPTR and SRV queries as specified in this document, if the UA is not able to resolve the URI of the proxy successfully to any IP address or if connecting to each of the resolved addresses fails, then the UA SHOULD try resolving the URI using the procedures defined in RFC 3263 [2]. Koivusalo Expires October 21, 2006 [Page 11] Internet-Draft Proxy Discovery for SIP Outbound April 2006 6. Examples As an example, consider a UA that wishes to resolve sip:example.com. The client performs a NAPTR query for that domain, and the following NAPTR records are returned: ; order pref flags service regexp replacement IN NAPTR 90 50 "s" "SIP-O+D2T" "" _sip._tcp.ob.example.com IN NAPTR 100 50 "s" "SIP-O+D2U" "" _sip._udp.ob.example.com IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.example.com IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.com. The UA will discard NAPTR records with "SIP+D2T" and "SIP+D2U" services. For the two NAPTR records indicating SIP Outbound support the one with TCP protocol is the preferred one. Consequently the UA will perform an SRV lookup of _sip._tcp.ob.example.com. That lookup would return: ;; Priority Weight Port Target IN SRV 0 1 5060 server1.example.com IN SRV 0 2 5060 server2.example.com IN SRV 1 1 5060 server3.example.com There are two priority levels amongst the returned SRV records. Assuming that all those servers are capable of responding SIP requests, the UA will pick the preferred server for each priority level and a send a REGISTER to them. Selecting the server within a priority level will be done based on the weight value of the SRV records. In this example the UA will send two REGISTER requests, one via server1.example.com and another via server3.example.com. Further on the UA will form and maintain flows towards both of those two proxies. Koivusalo Expires October 21, 2006 [Page 12] Internet-Draft Proxy Discovery for SIP Outbound April 2006 7. IANA Considerations This document instructs IANA to register the following values in the "Registry for the NAPTR Resource Record Services Field": Services Field Protocol Reference SIP-O+D2U UDP RFCXXX SIP-O+D2T TCP RFCXXX SIPS-O+D2T TCP RFCXXX SIP-O+D2S SCTP RFCXXX SIPS-O+D2S SCTP RFCXXX [[Note to IANA and the RFC Editor: Replace RFCXXX with the RFC number assigned to this specification]]. Koivusalo Expires October 21, 2006 [Page 13] Internet-Draft Proxy Discovery for SIP Outbound April 2006 8. Security Considerations DNS NAPTR records are used to allow a client to discover that the server supports SIP Outbound. An attacker could potentially modify these records, resulting the client to send STUN request to a proxy that does not support STUN requests in its SIP port. This kind of attack could cause the proxy to behave in an unpredictable way and might cause it to crash. This kind of attack is prevented by a mechansim introduced within draft-ietf-sip-outbound [8]. When sending REGISTER request, the UA has to add an option tag to it, requiring the proxy to reject the request if it does not support SIP Outbound [[Author's note: the mechanism to be used within REGISTER request is still to be decided. After the decision is made the text above must be rewritten.]] Other relevant security considerations have already been covered within RFC 3263 [2]. Koivusalo Expires October 21, 2006 [Page 14] Internet-Draft Proxy Discovery for SIP Outbound April 2006 9. Acknowledgments The author would like to thank Juha Heinanen, Fredrik Thulin and Miguel Garcia for their useful comments. Koivusalo Expires October 21, 2006 [Page 15] Internet-Draft Proxy Discovery for SIP Outbound April 2006 10. References 10.1. Normative References [1] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)", RFC 4168, October 2005. [2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [3] 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. [4] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000. [5] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [8] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", draft-ietf-sip-outbound-03 (work in progress), March 2006. 10.2. Informative References [9] Camarillo, G., "Compressing the Session Initiation Protocol (SIP)", RFC 3486, February 2003. Koivusalo Expires October 21, 2006 [Page 16] Internet-Draft Proxy Discovery for SIP Outbound April 2006 Author's Address Erkki Koivusalo Nokia Valimotie 9 Helsinki, 00380 Finland Phone: +358 40 757 1197 Email: erkki.koivusalo@nokia.com Koivusalo Expires October 21, 2006 [Page 17] Internet-Draft Proxy Discovery for SIP Outbound April 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.