SIPPING WG C. Jennings, Ed. Internet-Draft Cisco Systems Expires: April 18, 2005 A. Hawrylyshen, Ed. Jasomi Networks October 18, 2004 SIP Conventions for Connection Usage draft-jennings-sipping-outbound-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 18, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract SIP has many situations where a request can only be routed over an existing connection. This can arise in cases with firewall or network address translation (NAT) devices in the network path, over both UDP and TCP. TLS is also affected when the user agent (UA) does not have a certificate suitable for mutual TLS authentication. This draft addresses how user agents and proxies need to behave to work in these environments, and addresses keep-alive and DNS configuration issues required for high reliability connections in situations where Jennings & Hawrylyshen Expires April 18, 2005 [Page 1] Internet-Draft SIP with Outbound Only Connections October 2004 the UA can form connections to the proxy but the reverse is not generally true. This work is being discussed on the sipping@ietf.org mailing list. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 3.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 4. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1 Single Registrar and UA . . . . . . . . . . . . . . . . . 5 4.2 Multiple Connections from a User Agent . . . . . . . . . . 7 4.3 Edge Proxies . . . . . . . . . . . . . . . . . . . . . . . 7 4.4 Edge Proxies and Redirection . . . . . . . . . . . . . . . 8 5. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1 User Agent . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2 Registrar / Proxy . . . . . . . . . . . . . . . . . . . . 9 5.3 Edge Proxy . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 10.2 Informative References . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . 13 Jennings & Hawrylyshen Expires April 18, 2005 [Page 2] Internet-Draft SIP with Outbound Only Connections October 2004 1. Introduction There are many environments for SIP deployments where the user-agent (UA) can form a connection to the Registrar or Proxy but the connections in the reverse sense are not generally possible. This can happen for several reasons. It is important to understand that most IP phones and and soft-phones get their network configuration via a host-configuration protocol such as DHCP, they typically do not have a useful name in DNS, and they definitely do not have a long term stable DNS name that is appropriate for binding to a certificate. It is not practical for them to have a certificate that can be used as a client-side TLS certificate. However, they do support TLS and form TLS connections to a Proxy which the UA authenticates using TLS and the Proxy authenticates the UA using a digest challenge. There may be a firewall device between the UA and Proxy that only allows connections in the "outbound" direction. Similarly there may be a NAT that is only capable of allowing connections in the "outbound" direction. It is worth noting that most UAs in the world are deployed behind a firewall or NAT. This document describes several concepts that are used to solve this problem using a key idea from the connection reuse draft [9]: A Proxy that wishes to route a request to a particular AOR, say alice@example.com, may use any connection to Alice's UA which had previously authenticated at an appropriate level to allow it to change the registration bindings for Alice. Secondly, for high reliability systems, the UA needs to keep a connection to the Proxy that the Proxy can use at any time. This is achieved by having the UA keep multiple connections, referred to as "flows", to the Proxy and using a keep alive mechanism on each flow so that the UA can detect when it has failed and establish a new one. The overall approach can be summarized simply: UAs use a keep alive mechanism to keep their flow to the proxy alive. For TCP, TLS, and other connection oriented protocols this is a burst containing a CRLF payload, and for UDP it is a STUN request over the flow. A UA can create more than one flow using multiple registrations for the same contact and AOR. The instance id in the contact is used to identify the UA that a connection is associated with. A new contact parameter called connection-id is used to allow the proxy and registrar to tell the difference between a UA re-registering and registering an additional connection. The proxies keep track of the "flows" or connection mappings for successful registrations. When a proxy goes to route a message to a UA for which it has a Jennings & Hawrylyshen Expires April 18, 2005 [Page 3] Internet-Draft SIP with Outbound Only Connections October 2004 mapping, it can use any one of the flows on which a successful registration was completed for that contact. A failure on a particular flow can be retried on an alternate flow. 2. Requirements Must be able to detect that a UA supports these mechanisms. Support UA behind NATs. Support UA behind firewalls. Detect failure of connection and be able to correct for this. Support TLS to UA without stable DNS name or IP. Support many UAs simultaneously rebooting. Support a NAT rebooting or resetting. Support Proxy farms with multiple hosts for scaling and reliability purposes. Minimize initial start up load on a proxy (sort of apple pie). 3. Conventions & 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 [1]. 3.1 Definitions 'Edge Proxy': An Edge Proxy is any proxy that is located topologically between the registering user agent and the registrar. 'Flow': A Flow is a network protocol level connection between two endpoints that is represented by the network address of both ends and the protocol. For TCP and UDP this would include IP addresses and ports of both ends and the protocol (TCP or UDP). 'Outbound Connection': An Outbound Connection is a connection between two network elements that can only be established by one party. Typically this is due to network policy from a firewall or NAT device or it is due to issues with TLS where one end does not have a certificate that can be used as a server certificate so cannot act as a TLS server. Jennings & Hawrylyshen Expires April 18, 2005 [Page 4] Internet-Draft SIP with Outbound Only Connections October 2004 4. Approach Several scenarios where this technique is useful are discussed below, including the simple collocated Registrar - Proxy, a user agent desiring multiple connections to a resource (for redundancy for example) and Edge Proxy connection examples. This section explains the details of the approach while section (Section 5) has the exact details of how various elements handle messages. 4.1 Single Registrar and UA User Agents forming only a single connection continue to register in the normal way but include the instance identifier as described in the GRUU [8] and can also add a connection-id parameter with a value to the Contact header field value. These are used to allow the registrar to detect and remove invalid contacts when a UA reboots and described later in this section. For clarity, here is an example. Alice's UA creates a new TCP flow to the proxy and sends the following register. REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK-bad0ce Max-Forwards: 70 From: Alice ;tag=d879h76 To: Alice Call-ID: 8921348ju72je840.204 CSeq: 1 REGISTER Contact: ; connection-id=1; ;+sip.instance="" Content-Length: 0 The proxy would challenge this registration as normal to authenticate the sender. When the registrar adds an entry for this contact under the AOR for Alice, the registrar also needs to form a sublist under this contact that keeps track of the flow that received this registration and the connection-id value. Later when Bob sends a request to Alice at the proxy, the proxy follows normal rules from [2] to select a contact to send it to. The proxy then looks and finds the flows that have registrations to this contact. It forwards the request on that flow instead of trying to form a new connection to that contact. This allows the proxy to forward a request to a particular contact down the same flow that did the registration for that contact. Jennings & Hawrylyshen Expires April 18, 2005 [Page 5] Internet-Draft SIP with Outbound Only Connections October 2004 The keep alive mechanism needs to detect both failure of a connection and when the NAT public mapping has changed. When a residential NAT is rebooted, the UA needs to understand that its bindings are no longer valid and it needs to reregister. Simply sending keep alive packets will not detect this failure when using UDP. With connection oriented transports such as TCP or TLS, the keep alive will detect failure after a NAT reboot. Connection oriented transport failures are detected as the UA periodically sends a CRLF over the connection; if the connection has failed, a connection level error will be reported to the UA. A CRLF can be considered the beginning of the next message that will be sent and therefore is backwards compatible with existing standards. The TCP KEEP_ALIVE mechanism is not used because many operating systems do not allow this to be set on a per connection basis. The keep alive mechanism for UDP is quite different. The UA needs to detect when the connection is working but also when the flow definition has changed. A flow definition could change because a NAT device in the network path reboots and the resulting pubic address mapping for the UA changes. STUN [4] requests are sent over the connection that is being used for the UDP SIP traffic. The Proxy acts as a STUN server on the SIP signaling port. The STUN mechanism is very robust and allows the detection of a changed IP address. It may also be possible to do this with OPTIONS messages and rport; although this approach has the advantage of being backwards compatible, it also increases the load on the proxy server significantly. If the UA detects that the connection has failed or that the flow definition has changed, it will re-register using a back-off mechanism described in Section 5.1. in order to provide congestion relief when a large number of agents simultaneously reboot. The registrar saves the instance id (as defined in GRUU [8]) and connection-id (as defined in Section 6) along with the rest of the contact Header. If the instance id and connection-id are the same as a previous registration, the previous mapping is replaced on a successful registration response. This allows a UA that has rebooted to replace its previous registration for each flow with minimal impact on overall system load. If the TCP flow to the registrar is closed, any map entries referring to that flow must be removed. Similarly, if the registration expires, any map entries created by it need to be removed. A note about the UUID: A device like a soft-phone, when first installed, should generate a UUID [6] and then save this in Jennings & Hawrylyshen Expires April 18, 2005 [Page 6] Internet-Draft SIP with Outbound Only Connections October 2004 persistent storage for all future use. For a device such as a hard phone, which will only ever have a single SIP UA present, the UUID can be generated at any time because it is guaranteed that no other UUID is being generated at the same time on that physical device. This means the value of the time component of the UUID can be arbitrarily selected to be any time less than the time when the device was manufactured. A time of 0 (as shown in the example) is perfectly legal. 4.2 Multiple Connections from a User Agent A UA that forms two or more flows has similar behavior to a UA that forms a single connection but has some additional requirements. The UA MAY be configured with a primary and backup outbound proxy or it MAY select two flows to form using the DNS selection mechanism described in this section. The registration on each flow MUST contain the instance identifier from the GRUU mechanisms and MUST also add a different connection-id parameter to the Contact header so that the Registrar can differentiate the flows as being distinct connections from the same instance. For example, the connection-id value might be set to 1 for the primary connection and 2 for the backup connection. A UA that needs to establish multiple flows needs a way to use DNS to select candidate addresses for the formation of flows. The recommended way to do this is look at the DNS records resulting from the algorithm described in [3] and select distinct addresses from the target set. Hosts that are multi-homed can avoid complications by ensuring that interfaces that are in separate routing domains have distinct DNS names for each routing domain. Having different SRV records point to the same host record should also be considered in the implementation of a selection mechanism. Multiple interfaces in a single network should either be absent from DNS or preferably share an address. These guidelines will help prevent a UA from establishing flows that connect to the same resource and thereby unintentionally eliminating the desired redundancy. When a proxy goes to route a call to a particular contact, it can use the flow for any registration to that contact. If it detects that one has failed, it needs to remove that one and use the others. 4.3 Edge Proxies Some registration services are distributed so that there is an edge proxy between the UA and registrar. These systems can use effectively the same mechanism as described above but need to use the Jennings & Hawrylyshen Expires April 18, 2005 [Page 7] Internet-Draft SIP with Outbound Only Connections October 2004 Path header. The edge proxy keeps a similar map. When the edge proxy receives a registration, it needs to create an identifier value that is unique to this AOR, contact, connection-id, and instance-id and put this identifier in the path header. This is done by putting the value in the user portion of a loose route in the path header. If the registration succeeds, the edge proxy needs to map future requests that are routed to the identifier value that was put in the path header to the associated flow. The edge proxy needs to ensure that a 200 response to a register request represents a successful registration and not some spoofed traffic to the edge proxy. One way this can be done is by ensuring that it only pays attention to responses received over a TLS connection from a proxy that is authoritative for the domain of the registration. As an alternative to actually storing the state for the mapping in the edge proxy, the proxy can form an encrypted version of the flow identifier and put it in the path header so that the edge proxy will get it back from the registrar at the time it needs it. 4.4 Edge Proxies and Redirection Still work TODO here ... If Alice calls Bob, the Registrar for Bob can send a 302 redirecting Alice to Bob's edge proxy. TODO show how the path header that the edge proxy put in the Register gets copied to Alice and returned to the edge proxy and thus the whole thing works out fine. 5. Mechanisms 5.1 User Agent User Agents MUST support the the instance identifier as described in the GRUU [8] mechanism. If the UA detects that the binding on a NAT has changed, it MUST treat this as a connection failure and re-register. When registration fails due to a network problem or the Registrar does not respond, the UA maintains a range value for computing when it should next attempt to register. This range value SHOULD have an initial value of 1 minute and SHOULD double after each consecutive failed registration attempt, up to a maximum of 30 minutes. When a registration fails due to network problems, the UA MUST randomly select a time to re-register that is between 50 and 100 percent of the current range value. A User Agent that forms two or more connections has similar behavior to a User Agent that forms single connections but has some additional requirements. All User Agents SHOULD support forming multiple connections. The UA MAY be configured with a primary and backup outbound proxy. It MUST support selecting at least two connections Jennings & Hawrylyshen Expires April 18, 2005 [Page 8] Internet-Draft SIP with Outbound Only Connections October 2004 using the mechanism described in Location of SIP Servers [3]. When DNS is used, the UA finds IP addresses used for registration the normal way, but if it discovers more than one possible IP address, it SHOULD connect to two distinct addresses of the possible IP addresses. Each connection MUST contain the instance identifier from the GRUU mechanisms but MUST also add a distinct connection-id parameter to the contact header field value so that the Registrar can differentiate the two connections as being from the same instance but different connections. The connection-id MAY be set to 1 for the primary connection and 2 for the backup connection. On connection oriented transports such as TCP or TLS, if no other traffic has been sent for 600 (TODO 30 or 600) seconds, then the UA MUST send a CRLF to detect whether the connection has failed. On UDP connections, the UA MUST send a STUN [4] request every 30 seconds over the same flow as the SIP signaling. If the UA detects that the flow has changed, it MUST reregister. 5.2 Registrar / Proxy When a registrar receives a registration over a particular flow that contains an instance identifier and connection id, it processes the registration as normal, and if it is successful, it MUST append the connection-id and reference to the flow to a list that is maintained for this particular AOR and contact. If the list already has an entry with the same connection-id, the registrar MUST replace the previous entry with the current one. If the registrar proxies a request to a particular contact, it MUST use one of the flows it has saved for this contact. If it detects a transport failure on this flow, it MUST remove the entry for that flow from the list. 5.3 Edge Proxy When an edge proxy receives a registration request, it MUST form a registration identifier that is unique to this AOR and contact and include that identifier in the path header it adds to the registration. When an edge proxy receives a 200 response to a registration it MUST ensure that this response came from the edge proxy or registrar that the edge proxy sent the request to. This can be accomplished using mutual TLS or pre-configuring the network such that only the registrar can send traffic to the side of the edge proxy that accepts the 200. Once the 200 is determined to be a valid response for the Jennings & Hawrylyshen Expires April 18, 2005 [Page 9] Internet-Draft SIP with Outbound Only Connections October 2004 request, the edge proxy MUST append the connection id and a reference to the flow on which the request was received to a list that is for this particular AOR, contact and instance id. If the list already has an entry with the same connection id, it MUST replace that entry. If the edge proxy receives a request that is routed to a registration identifier that it created, then it MUST forward the request on one of the flows it has saved for this contact. If it detects a transport failure on this flow, it MUST remove the entry for that flow from the list. 6. Grammar This specification defines a new Contact header field parameter, connection-id. The grammar for pvalue and EQUAL is obtained from RFC 3261 [2]. contact-params = c-p-q / c-p-expires / contact-extension c-p-connection c-p-connection = "connection-id" EQUAL pvalue ; defined in RFC3261 7. IANA This specification defines a new Contact header field parameter called connection-id, as per the registry created by [5]. The required information is as follows: Header field in which the parameter can appear: Contact Name of the Parameter: connection-id RFC Reference: RFC AAAA [NOTE TO IANA: Please replace AAAA with the RFC number of this specification.] 8. Security Considerations One of the key security concerns in this work is making sure that an attacker can not hijack the sessions of a valid user and cause all calls destined to that user to be sent to the attacker instead. The simple case to look at is when there are no edge proxies. In this case, the only time an entry can be added to the routing for a Jennings & Hawrylyshen Expires April 18, 2005 [Page 10] Internet-Draft SIP with Outbound Only Connections October 2004 given AOR is when the registration succeeds. SIP protects against attackers being able to successfully register, and this scheme relies on that security. The more complex case involves one or more edge proxies. This case is similar to the simple proxy case in that the only time a table is updated is when there has been a valid registration for that AOR. It is critical that the edge proxy only use a 200 that came from the registrar to decide that the registration was valid. An attacker could send a bad registration and also spoof a 200 to this registration, which would make the attack look like a valid registration to the edge proxy. This would allow the attacker to hijack an arbitrary connection. 9. Acknowledgments Rohan Mahy had the insight key to this draft, that registration can be used to authorize connection reuses. The TCP design team consisting of Chris Boulton, Scott Lawrence, Rajnish Jain, Vijay K. Gurbani, and Ganesh Jayadevan provided input. Additionally, many of the concepts here originated at a connection reuse meeting at IETF 60 that included Jon Peterson, Jonathan Rosenberg, Paul Kyzivat and Rohan Mahy. 10. References 10.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] 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. [3] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [4] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [5] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", draft-ietf-sip-parameter-registry-02 (work in progress), June 2004. [6] Mealling, M., "A UUID URN Namespace", draft-mealling-uuid-urn-03 Jennings & Hawrylyshen Expires April 18, 2005 [Page 11] Internet-Draft SIP with Outbound Only Connections October 2004 (work in progress), March 2004. [7] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [8] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft-ietf-sip-gruu-02 (work in progress), July 2004. 10.2 Informative References [9] Mahy, R., "Connection Reuse in the Session Initiation Protocol (SIP)", draft-ietf-sip-connect-reuse-02 (work in progress), July 2004. [10] Mahy, R., "Requirements for Connection Reuse in the Session Initiation Protocol (SIP)", draft-ietf-sipping-connect-reuse-reqs-00 (work in progress), October 2002. Authors' Addresses Cullen Jennings (editor) Cisco Systems 170 West Tasman Drive Mailstop SJC-21/2 San Jose, CA 95134 USA Phone: +1 408 902-3341 EMail: fluffy@cisco.com Alan Hawrylyshen (editor) Jasomi Networks 310, 602 - 11 Ave SW Calgary, Alberta T2R 1J8 Canada Phone: +1 866 617 8647 EMail: alan@jasomi.com Jennings & Hawrylyshen Expires April 18, 2005 [Page 12] Internet-Draft SIP with Outbound Only Connections October 2004 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 (2004). 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. Jennings & Hawrylyshen Expires April 18, 2005 [Page 13]