| TOC |
|
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 26, 2006.
Copyright © The Internet Society (2005).
When SIP entities use a connection oriented protocol to send a request, they typically originate their connections from an ephemeral port. The SIP protocol includes mechanisms which insure that responses to a request, and new requests sent in the original direction reuse an existing connection. However, new requests sent in the opposite direction are unlikely to reuse the existing connection. This frequently causes a pair of SIP entities to use one connection for requests sent in each direction, and can result in potential scaling and performance problems. This document proposes requirements and a mechanism which address this deficiency in environments where the connection could be opened in either direction.
1.
Conventions
2.
Introduction and Problem Statement
2.1
Efficiency Concerns
2.2
Directional Connectivity
2.3
Clustering
2.4
Hop-by-hop reuse
3.
Requirements
4.
Behavior
4.1
Authorizing an alias request
4.1.1
Authorizing using TLS mutual authentication
4.2
Formal Syntax
5.
Security Considerations
6.
IANA Considerations
7.
Acknowledgments
8.
References
8.1
Normative References
8.2
Informational References
§
Author's Address
§
Intellectual Property and Copyright Statements
| TOC |
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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.)[4].
| TOC |
SIP (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)[3] entities can communicate using either unreliable/connectionless (ex: UDP) or reliable/connection-oriented (ex: TCP, SCTP (Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, “Stream Control Transmission Protocol,” October 2000.)[13]) transport protocols. When SIP entities use a connection-oriented protocol (such as TCP or SCTP) to send a request, they typically originate their connections from an ephemeral port.
In the following example, Entity A listens for SIP requests over TLS (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.)[5] on TCP port 5061 (the default port for SIP over TLS over TCP), but uses an ephemeral port (port 8293) for a new connection to Entity B. These entities could be SIP User Agents or SIP Proxy Servers.
+-----------+ 8293 (UAC) 5061 (UAS) +-----------+
| |--------------------------->| |
| Entity | | Entity |
| A | | B |
| | 5061 (UAS) | |
+-----------+ +-----------+
The SIP protocol includes mechanisms which insure that responses to a request reuse the existing connection which is typically still available, and also includes provisions for reusing existing connections for other requests sent by the originator of the connection. However, new requests sent in the opposite direction (routed from the target of the original connection toward the originator of the original connection) are unlikely to reuse the existing connection. This frequently causes a pair of SIP entities to use one connection for requests sent in each direction, as shown below.
+-----------+ 8293 5061 +-----------+
| |.......................>| |
| Entity | | Entity |
| A | 5061 9741 | B |
| |<-----------------------| |
+-----------+ +-----------+
SIP entities can use the mechanism described in this document to reuse connections when the two entities are agnostic about the direction of the connection (either end can initiate the connection). SIP entities that can only open a connection in a specific direction reuse their connections instead using the mechanism described in Managing Client Initiated Connections in SIP (Jennings, C. and R. Mahy, “Managing Client Initiated Connections in the Session Initiation Protocol (SIP),” July 2005.)[1].
Opening an extra connection where an existing one is sufficient can result in potential scaling and performance problems. For example, each new connection using TLS requires a TCP 3-way handshake, a handful of round-trips to establish TLS, and (typically) expensive asymmetric authentication and key generation algorithms, and certificate verification. This effectively doubles the load on each entity. Setting up a second connection can also cause excessive delay (especially in networks with long round-trip times) for subsequent requests, even requests in the context of an existing dialog (for example a reINVITE or BYE after an initial INVITE, or a NOTIFY after a SUBSCRIBE [12] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) or a REFER (Sparks, R., “The Session Initiation Protocol (SIP) Refer Method,” April 2003.)[11]).
Consider the call flow shown below where Proxy A and Proxy B use the Record-Route mechanism to stay involved in a dialog. Proxy B will establish a new TLS connection just to send a BYE request.
INVITE -> create connection 1 <- 200 response over connection 1 ACK -> reuse connection 1 <- BYE create connection 2 -> 200 response over connection 2
ReINVITEs or UPDATE (Rosenberg, J., “The Session Initiation Protocol (SIP) UPDATE Method,” October 2002.)[8] requests are expected to be handled automatically and rapidly in order to avoid media and session state from being out of step. If a reINVITE requires a new TLS connection, the reINVITE could be delayed by several extra round-trip times. Depending on the round-trip time, this combined delay could be perceptible or even annoying to a human user. This is especially problematic for some common SIP call flows (for example, the recommended example flow in figure number 4 in RFC3725 (Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, “Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP),” April 2004.)[9] (SIP third-party call control) use many reINVITEs.
Some SIP User Agents can initiate TCP or TLS connections, but for one reason or another cannot usefully accept incoming connections. When TLS connections are involved, many User Agents can accept incoming TLS connections, but cannot provide a certificate that is likely to be trusted by the TLS client. (The User Agent can only offer a self-signed certificate for example.) This causes their connectivity to fail.
In other cases, a User Agent cannot accept incoming TCP connections at all because they are behind a Firewall or NAT.
+---+
+-----------+ | | +-----------+
| |-----| |--------->| |
| User | | F | | Proxy |
| Agent A | | W | | Server |
| | | X<---------| |
+-----------+ | | +-----------+
+---+
Finally, some User Agents may be configured to refuse incoming TCP or TLS connections, since it is difficult or impossible for some class of User Agents to authorize such connections.
In all three of these cases, some form of connection reuse is no longer simply an efficiency improvement. It is mandatory to make TCP or TLS work for a large class of SIP User Agents. For User Agents in this class, incoming requests need to come from a proxy server with which the User Agent has a persistent connection. Each User Agent in this class of UAs also needs to have a SIP URI with GRUU (Rosenberg, J., “Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP),” September 2005.)[2] properties that routes to a proxy server that knows how to forward requests over a persistent connection already opened by the User Agent. However, just using the GRUU mechanism by itself does not help a proxy server determine which incoming persistent connection is associated with a particular GRUU. An explicit connection management mechanism for outbound connections is still needed between these User Agents and their proxies. Mechanisms for addressing the requirements of this class of User Agents are out of scope for this document, but are instead discussed in [1] (Jennings, C. and R. Mahy, “Managing Client Initiated Connections in the Session Initiation Protocol (SIP),” July 2005.).
For example, consider a standard SIP presence (Rosenberg, J., “A Presence Event Package for the Session Initiation Protocol (SIP),” August 2004.)[10] subscription. An instant messaging and presence client sends a SUBSCRIBE request for the presence of a peer. The presence notifications are returned as NOTIFY requests from the peer. If the subscribing User Agent wants to use TLS, the NOTIFY request would cause a second (new) connection back to the subscribing client. If the presence client doesn't have a valid TLS certificate anchored in a well-known certificate authority, the NOTIFY request will fail, and the presence client will never receive any presence data.
SUBSCRIBE -> connection 1 <- 202 connection 1 <- NOTIFY connection 2 200 -> connection 2
When clusters or farms of cooperating SIP servers (for example proxy servers) are configured together, SIP entities have no way to prefer a server with an existing connection. For example, Proxy server B has no mechanism to choose an existing connection with Proxy cluster A.
+-----------+
| |
| Proxy |
| A1 | +-----------+
| | | |
+-----------+ | Proxy |
+-----------+ 8293 5061 | B |
| |----------------------->| |
| Proxy | +-----------+
| A2 |
| |
+-----------+
As a result, Proxy B might open a new connection to another proxy server for requests sent in the opposite direction.
+-----------+
| |
| Proxy |
| A1 | 5061 9741 +-----------+
| |<.......................| |
+-----------+ | Proxy |
+-----------+ 8293 5061 | B |
| |----------------------->| |
| Proxy | +-----------+
| A2 |
| |
+-----------+
The rules for handling the Transport layer described in Section 18 of SIP (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)[3] do not associate incoming connections with the listening port which corresponds to the same SIP entity. If the Transport layer had some way to associate these connections, then request and responses originated from either node could reuse existing connections as shown below.
+-----------+ +-----------+
| | | |
| Node A | 8293 5061 | Node B |
| |<======================>| |
| | | |
+-----------+ +-----------+
Similarly, when when an "outbound-only" user agent opens a connection to only one proxy server in the same cluster, there is no way for this user agent to receive incoming requests if the this particular proxy goes down. In many scenarios, the user agent would not notice the connection was unresponsive until it was time to refresh its SIP registration. Some "outbound-only" user agents would like the ability to open persistent connections to more than one proxy server in a cluster, so that at least two proxy servers in the cluster can forward incoming requests to the user agent. This requirements of these "outbound-only" user agents are discussed in [1] (Jennings, C. and R. Mahy, “Managing Client Initiated Connections in the Session Initiation Protocol (SIP),” July 2005.).
All the examples presented above apply to a single hop as opposed to a per-dialog route-set or other complete path. This is natural since ordinary connections are managed on a hop-by-hop basis as well. Proxy server to proxy server connection reuse is likely to be much more efficient if multiple dialogs or multiple users can use the same connection.
| TOC |
| TOC |
The proposed mechanism uses a new Via header field parameter. The "alias" parameter is included in a Via header field value to indicate that the originator of the request wants to create a transport layer alias. The originator places their alias in the Via header field value (in the "sent-by" production). This "alias" address becomes mapped to the a actual IP address and port number observed as the source address of the current connection.
Assuming the Via header field value shown below from the most recent request arrived over a connection from 10.54.32.1 port 8241:
Via: SIP/2.0/TLS 10.54.32.1:5061;branch=z9hG4bKa7c8dze ;alias
The transport layer creates an alias, such that any requests going to the "advertised address" (10.54.32.1 port 5061) are instead sent over the existing connection (to the "target" of the alias) which is coming from port 8241. This sharing continues as long as the target connection stays up.
The SIP community recommends that servers keep connections up unless they need to reclaim resources, and that clients keep connections up as long as they are needed. Connection reuse works best when the client and the server maintain their connections for long periods of time. SIP entities therefore SHOULD NOT drop connections on completion of a transaction or termination of a dialog.
To implement connection aliases for explicit IP addresses and port numbers, a SIP node could (for example) search an additional data structure (the alias table) prior to opening a new connection, or could modify the data structure in which it keeps active connection state so that aliases, active connections, and blacklisted nodes are all discovered when looking for an active connection.
Likewise when clusters or farms of cooperating SIP servers (for example proxy servers) are configured together, this mechanism allows a SIP entity to select a server with an existing connection. With this mechanism, Proxy B sends requests for Proxy cluster A to node A2 with whom it already shares an existing connection.
+------------+
| Proxy |
| A1 |
| | +-----------+
| 10.54.32.1 | | |
+------------+ | Proxy |
+------------+ 8293 5061 | B |
| Proxy |<======================>| |
| A2 | +-----------+
| |
| 10.54.32.2 |
+------------+
For example, on receipt of a message with the topmost Via header shown below, the transport layer in Proxy B creates an alias such that requests going to the advertised address (proxy-farm-a.example.com) are sent over the target connection (from 10.54.32.2:8293).
Via: SIP/2.0/TLS proxy-farm-a.example.com;branch=z9hG4bK7c8ze;alias ;received=10.54.32.2
As a result, this has an important interaction with the DNS resolution mechanisms for SIP described in RFC3263 (Rosenberg, J. and H. Schulzrinne, “Session Initiation Protocol (SIP): Locating SIP Servers,” June 2002.)[6]. When new requests arrive for proxy-farm-a.example.com, proxy B still needs to perform a DNS NAPTR lookup to select the transport. Once the transport is selected, an SRV lookup would ordinarily occur to find the appropriate port number. In this case, the transport layer uses a connection reuse alias instead of performing the SRV query.
Below is a partial DNS zone file for atlanta.com.
; NAPTR queries for the current domain (example.com) ; ; order pref flags service regexp replacement proxy-farm-a IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp. ; SRV records for the proxy use 5060/5061 ; ;; Priority Weight Port Target _sips._tcp.proxy-farm-a IN SRV 0 1 5061 host-a1 _sips._tcp.proxy-farm-a IN SRV 0 1 5061 host-a2 host-a1 IN A 10.54.32.1 host-a2 IN A 10.54.32.2
The existence of an alias parameter in a Via header in a request is treated as a request to the transport layer to create an alias (named by the sent-by parameter) that points to the alias target (the current connection)
This mechanism is fully backwards compatible with existing implementations. If the new Via parameter is not understood by the recipient, it will be ignored and the two implementations will revert to current behavior (two connections).
Authorizing connection aliases is essential to prevent connection hijacking. For example a program run by a malicious user of a multiuser system could attempt to hijack SIP requests destined for the well-known SIP port from a large relay proxy.
To correctly authorize an alias, the SIP node authorizing the request needs to recognize both the active connection and the alias as the same resource. The only way to accomplish this is if both the active connection and the alias can be authenticated using the same credentials. In this specification, this is accomplished using TLS mutual authentication.
The authorization mechanism for this mechanism requires TLS mutual authentication, such that the subjectAltName of the originator certificate corresponds to both the current connection and the target address of the alias. The Via sent-by address needs to be within the scope protected by the certificate presented by the originator during TLS mutual authentication and the received IP address needs be a valid IP address for the sent-by host or hosts. In other words, the sent-by address MUST be resolvable from the subjectAltName of the originator certificate, and the received IP address MUST be resolvable from the sent-by address. This is in addition to other requirements for TLS authentication and authorization discussed in SIP (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)[3] and Locating SIP Servers (Rosenberg, J. and H. Schulzrinne, “Session Initiation Protocol (SIP): Locating SIP Servers,” June 2002.)[6].
Following this logic step-by-step:
For example, take the example in the previous section of proxy B receiving an alias request from host-a2.example.com. Proxy B verifies that the presented certificate is valid and trusted. Proxy B checks that proxy-farm-a.example.com is both the advertised name and the subjectAltName in the certificate. Finally, proxy B verifies that this connection is coming from 10.54.32.2, which is one of the addresses in DNS for host-a2.example.com, which in turn is mentioned in an SRV record for _sips._tcp.proxy-farm-a.example.com.
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.)[7]. This document proposes to extend via-params to include a new via-alias defined below.
via-params = via-ttl / via-maddr / via-received / via-branch /
via-alias / via-extension
via-alias = "alias"
| TOC |
This document presents requirements and a mechanism for reusing existing connections easily. Unauthorized connection reuse would present many opportunities for rampant abuse and hijacking, but these attacks can be prevented if the guidelines in Section 4.1 (Authorizing an alias request) are followed.
The mechanism in this document can significantly improve the security of SIP networks, in that it makes SIP over TLS (and the sips: scheme) practical for devices which do not have a certificate rooted in a well-known certificate authority.
SIP Proxy Servers which implement this mechanism MUST implement TLS mutual authentication, and MUST follow the authorization rules described in Section 4.1.1 (Authorizing using TLS mutual authentication).
| TOC |
This document adds a parameter to the SIP header field parameters registry:
Header field in which parameter can appear: Via Name of the parameter: alias Reference: This document
| TOC |
Thanks to Jon Peterson for helpful answers about certificate behavior with SIP, Jonathan Rosenberg for his initial support of this concept, and Cullen Jennings for providing a sounding board for this idea.
| TOC |
| TOC |
| [1] | Jennings, C. and R. Mahy, “Managing Client Initiated Connections in the Session Initiation Protocol (SIP),” draft-ietf-sip-outbound-00 (work in progress), July 2005. |
| [2] | Rosenberg, J., “Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP),” draft-ietf-sip-gruu-05 (work in progress), September 2005. |
| [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] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [5] | Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” RFC 2246, January 1999. |
| [6] | Rosenberg, J. and H. Schulzrinne, “Session Initiation Protocol (SIP): Locating SIP Servers,” RFC 3263, June 2002. |
| [7] | Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” RFC 2234, November 1997. |
| TOC |
| [8] | Rosenberg, J., “The Session Initiation Protocol (SIP) UPDATE Method,” RFC 3311, October 2002. |
| [9] | Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, “Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP),” BCP 85, RFC 3725, April 2004. |
| [10] | Rosenberg, J., “A Presence Event Package for the Session Initiation Protocol (SIP),” RFC 3856, August 2004. |
| [11] | Sparks, R., “The Session Initiation Protocol (SIP) Refer Method,” RFC 3515, April 2003. |
| [12] | Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” RFC 3265, June 2002. |
| [13] | Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, “Stream Control Transmission Protocol,” RFC 2960, October 2000. |
| TOC |
| Rohan Mahy | |
| SIP Edge LLC | |
| Email: | rohan@ekabal.com |
| TOC |
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.
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 © The Internet Society (2005). 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.
Funding for the RFC Editor function is currently provided by the Internet Society.