Connection Reuse in the Session Initiation Protocol (SIP)
DOCNAME

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, 2009.

Abstract

This document enables a pair of communicating proxies to reuse a congestion-controlled connection between themselves for sending requests in the forward and backwards direction. Because the connection is essentially aliased for requests going in the backwards direction, reuse is predicated upon both the communicating endpoints authenticating themselves using X.509 certificates through TLS. For this reason, we only consider connection reuse for TLS over TCP and TLS over SCTP. From the security perspective, it is bad practice to reuse a single connection for the TCP or SCTP transport between two peers, and this document provides specific insights into why this is the case. As a remedy, it suggests using two TCP connections (or two SCTP associations), each opened pro-actively towards the recipient by the sender. Finally, this document also provides guidelines on connection reuse and virtual SIP servers and the interaction of connection reuse and DNS SRV lookups in SIP.

Table of Contents

1.  Terminology
2.  Applicability Statement
3.  Introduction
4.  Benefits of TLS Connection Reuse
5.  Overview of Operation
6.  Requirements
7.  Formal Syntax
8.  Normative Behavior
    8.1.  Client Behavior
    8.2.  Server Behavior
9.  Security Considerations
    9.1.  Authenticating TLS Connections: Client View
    9.2.  Authenticating TLS Connections: Server View
    9.3.  Security Considerations for TCP and SCTP Transports
10.  Connection reuse and Virtual servers
11.  Connection Reuse and SRV Interaction
12.  IANA Considerations
13.  Acknowledgments
14.  References
    14.1.  Normative References
    14.2.  Informational References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

Additional terminology used in this document:

Advertised address:

The address that occurs in the Via header field's sent-by production rule, including the port number and transport.

Alias:

Re-using an existing connection for sending requests in the backwards direction; i.e., A opens a connection to B to send a request, and B uses that connection to send requests in the backwards direction to A.

Connection reuse:

See "Alias".

Persistent connection:

The process of sending multiple, possibly unrelated requests on the same connection, and receiving responses on that connection as well. More succinctly, A opens a connection to B to send a request, and later reuses the same connection to send other requests, possibly unrelated to the dialog established by the first request. Responses will arrive over the same connection. Persistent connection behavior is specified in Section 18 of RFC3261 [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.). Persistent connections do not imply connection reuse.

Resolved address:

The network identifiers (IP address, port, transport) associated with a user agent as a result of executing RFC3263 [RFC3263] (Rosenberg, J. and H. Schulzrinne, “Session Initiation Protocol (SIP): Locating SIP Servers,” June 2002.) on a Uniform Resource Identifier (URI).

Shared connection:

See "Persistent connection."

2.  Applicability Statement

The applicability of the mechanism described in this document is for two adjacent SIP entities to reuse connections when they are agnostic about the direction of the connection, i.e., either end can initiate the connection. SIP entities that can only open a connection in a specific direction -- perhaps because of Network Address Translation (NAT) and firewalls -- reuse their connections using the mechanism described in the outbound document [I‑D.ietf‑sip‑outbound] (Jennings, C. and R. Mahy, “Managing Client Initiated Connections in the Session Initiation Protocol (SIP),” June 2008.).

This memo concerns connection reuse, not persistent connections (see definitions of these in Section 1 (Terminology)). Behavior for persistent connections is specified in Section 18 of RFC3261 [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) and is not altered by this memo.

This memo documents that it is good practice to only reuse those connections where the identity of the sender can be verified by the receiver. Thus, TLS (RFC 5246 (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) [RFC5246]) connections (over any connection-oriented transport) formed by exchanging X.509 certificates can be reused because they authoritatively establish identities of the communicating parties (see Section 5 (Overview of Operation)). For reasons discussed in Section 9.3 (Security Considerations for TCP and SCTP Transports), connection reuse over other connection-oriented transport -- e.g., TCP, SCTP (RFC4960 (Stewart, R., “Stream Control Transmission Protocol,” September 2007.) [RFC4960]) -- is not advisable.

3.  Introduction

SIP entities can communicate using either unreliable/connectionless (e.g., UDP) or reliable/connection-oriented (e.g., TCP, SCTP) 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, A listens for SIP requests over TLS 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 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 the notion of a persistent connection, which is a mechanisms to insure that responses to a request reuse the existing connection that is typically still available, as well as reusing the existing connections for other requests sent by the originator of the connection. However, new requests sent in the backwards direction -- in the example above, requests from B destined to A -- 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     |
       |           |<-----------------------|           |
       +-----------+                        +-----------+

While this is adequate for TCP, TLS connections can be reused to send requests in the backwards direction since each end can be authenticated when the connection is initially set up. Once the authentication step has been performed, the situation can thought to resemble the picture in Figure 1 (Uni-directional connection for requests from A to B) except that the connection opened from A to B is shared; when A wants to send a request to B, it will reuse this connection, and when B wants to send a request to A, it will reuse the same connection.

4.  Benefits of TLS Connection Reuse

Opening an extra connection where an existing one is sufficient can result in potential scaling and performance problems. Each new connection using TLS requires a TCP three-way handshake, a handful of round-trips to establish TLS, typically expensive asymmetric authentication and key generation algorithms, and certificate verification. This can lead to a build up of considerable queues as the server CPU saturates by the TLS handshakes it is already performing (Section 6.19 of Rescorla [Book‑Rescorla‑TLS] (Rescorla, E., “SSL and TLS: Designing and Building Secure Systems,” 2001.)).

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.

                   Proxy A    Proxy B
                      |          |
  Create connection 1 +---INV--->|
                      |          |
                      |<---200---+ Response over connection 1
                      |          |
  Re-use connection 1 +---ACK--->|
                      |          |
                      =          =
                      |          |
                      |<---BYE---+ Create connection 2
                      |          |
       Response over  +---200--->|
       connection 2

Setting up a second connection (from B to A above) for subsequent requests, even requests in the context of an existing dialog (e.g., re-INVITE request or BYE request after an initial INVITE request, or a NOTIFY request after a SUBSCRIBE request or a REFER request), can also cause excessive delay (especially in networks with long round-trip times). Thus, it is advantageous to reuse connections whenever possible.

From the user expectation point of view, it is advantageous if the re-INVITE requests or UPDATE requests are handled automatically and rapidly in order to avoid media and session state from being out of step. If a re-INVITE request requires a new TLS connection, the re-INVITE request 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 H. Camarillo, “Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP),” April 2004.) [RFC3725] use many reINVITE requests).

The mechanism described in this document can mitigate the delays associated with subsequent requests.

5.  Overview of Operation

This section is tutorial in nature, and does not specify any normative behavior.

We now explain this working in more detail in the context of communication between two adjacent proxies. Without any loss of generality, the same technique can be used for connection reuse between a UAC and an edge proxy, or between an edge proxy and a UAS, or between an UAC and an UAS.

P1 and P2 are proxies responsible for routing SIP requests to user agents that use them as edge proxies (see Figure 4 (Proxy setup)).

                P1 <===================> P2
           p1.example.com          p2.example.net
            (192.0.2.1)              (192.0.2.128)

     +---+                                    +---+
     |   |   0---0                   0---0    |   |
     |___|    /-\                     /-\     |___|
    /    /   +---+                   +---+   /    /
   +----+                                   +----+
   User Agents                       User Agents
   example.com domain                example.net domain

For illustration purpose the discussion below uses TCP as a transport for TLS operations. Another streaming transport -- such as SCTP -- can be used as well.

The act of reusing a connection is initiated by P1 when it adds an "alias" header field parameter (defined later) to the Via header field. When P2 receives the request, it examines the topmost Via header field. If the Via header contained an "alias" header field parameter, P2 establishes a binding such that subsequent requests going to P1 will reuse the connection; i.e., requests are sent over the established connection.

With reference to Figure 4 (Proxy setup), in order for P2 to reuse a connection for requests in the backwards direction, it is important that the validation model for requests sent in this direction (i.e., P2 to P1) is equivalent to the normal "connection in each direction" model, wherein P2 acting as client would open up a new connection in the backwards direction and validate the connection by examining the X.509 certificate presented. The act of reusing a connection needs the desired property that requests get delivered in the backwards direction only if they would have been delivered to the same destination had connection reuse not been employed. To guarantee this property, the X.509 certificate presented by P1 to P2 when a TLS connection is first authenticated are cached for later use.

To aid the discussion of connection reuse, this document defines a data structure called the connection alias table (or simply, alias table), which is used to store aliased addresses and is used by user agents to search for an existing connection before a new one is opened up to a destination. It is not the intent of this memo to standardize the implementation of an alias table; rather we use it as a convenience to aid subsequent discussions.

P1 gets a request from one of its upstream user agents, and after performing RFC3263 [RFC3263] (Rosenberg, J. and H. Schulzrinne, “Session Initiation Protocol (SIP): Locating SIP Servers,” June 2002.) server selection, arrives at a resolved address of P2. P1 maintains an alias table, and it populates the alias table with the IP address, port number, and transport of P2 as determined through RFC3263 server selection. P1 adds an "alias" header field parameter to the topmost Via header field (inserted by it) before sending the request to P2. The value in the sent-by production rule of the Via header field (including the port number), and the transport over which the request was sent becomes the advertised address of P1:

Via: SIP/2.0/TLS p1.example.com;branch=z9hG4bKa7c8dze;alias

Assuming that P1 does not already have an existing aliased connection with P2, P1 now opens a connection with P2. P2 presents its X.509 certificate to P1 for validation (see Section 9.1 (Authenticating TLS Connections: Client View)). Upon connection authentication and acceptance, P1 adds P2 to its alias table. P1's alias table now looks like:

Destination  Destination  Destination  Destination      Alias
IP Address   Port         Transport    Identity         Descriptor
...
192.0.2.128  5061         TLS          sip:example.net     25
                                       sip:p2.example.net

Subsequent requests that traverse from P1 to P2 will reuse this connection; i.e., the requests will be sent over the descriptor 25.

The following columns in the alias table created at the client warrant an explanation:

1. The IP address, port and transport are a result of executing RFC3263 server resolution process on a next hop URI.
2. The entries in the fourth column consists of the identities of the server as asserted in the X.509 certificate presented by the server. These identities are cached by the client after the server has been duly authenticated (see Section 9.1 (Authenticating TLS Connections: Client View)).
3. The entry in the last column is the socket descriptor over which P1, acting as a client, actively opened a TLS connection. At some later time, when P1 gets a request from one of the user agents in its domain, it will reuse the aliased connection accessible through socket descriptor 25 if and only if all of the following conditions hold:

A.

P1 determines through the RFC3263 server resolution process that the {transport, IP-address, port} tuple of P2 to be {TLS, 192.0.2.128, 5061}, and

B.

The URI used for the RFC3263 server resolution matches one of the identities stored in the cached certificate (fourth column).

When P2 receives the request it examines the topmost Via header field to determine whether P1 is willing to use this connection as an aliased connection (i.e., accept requests from P2 towards P1.) The Via header field at P2 now looks like the following (the "received" header field parameter is added by P2):

Via: SIP/2.0/TLS p1.example.com;branch=z9hG4bKa7c8dze;alias;
  received=192.0.2.1

The presence of the "alias" Via header field parameter indicates that P1 supports aliasing on this connection. P2 now authenticates the connection (see Section 9.2 (Authenticating TLS Connections: Server View)) and if the authentication was successful, P2 creates an alias to P1 using the advertised address in the topmost Via header field. P2's alias table looks like the following:

Destination  Destination  Destination  Destination     Alias
IP Address   Port         Transport    Identity        Descriptor
...
192.0.2.1    5061             TLS      sip:example.com     18
                                       sip:p1.example.com

There are a few items of interest here:

1. The IP address field is populated with the source address of the client.
2. The port field is populated from the advertised address (topmost Via header field), if a port is present in it, or 5061 if it is not.
3. The transport field is populated from the advertised address (topmost Via header field).
4. The entries in the fourth column consist of the identities of the client as asserted in the X.509 certificate presented by the client. These identities are cached by the server after the client has been duly authenticated (see Section 9.2 (Authenticating TLS Connections: Server View)).
5. The entry in the last column is the socket descriptor over which the connection was passively accepted. At some later time, when P2 gets a request from one of the user agents in its domain, it will reuse the aliased connection accessible through socket descriptor 18 if and only if all of the following conditions hold:

A.

P2 determines through RFC3263 server resolution process that the {transport, IP-address, port} tuple of P1 to be {TLS, 192.0.2.1, 5061}, and

B.

The URI used for RFC3263 server resolution matches one of the identities stored in the cached certificate (fourth column).

6. The network address inserted in the "Destination IP Address" column is the source address as seen by P2 (i.e., the "received" header field parameter). It could be the case that the host name of P1 resolves to different IP addresses due to round-robin DNS. However, the aliased connection is to be established with the original sender of the request.

6.  Requirements

The following are the requirements that motivated this specification:

1. A connection sharing mechanism should allow SIP entities to reuse existing connections for requests and responses originated from either peer in the connection.
2. A connection sharing mechanism must not require clients to send all traffic from well-know SIP ports.
3. A connection sharing mechanism must not require configuring ephemeral port numbers in DNS.
4. A connection sharing mechanism must prevent unauthorized hijacking of other connections.
5. Connection sharing should persist across SIP transactions and dialogs.
6. Connection sharing must work across name-based virtual SIP servers.
7. There is no requirement to share a complete path for ordinary connection reuse. Hop-by-hop connection sharing is more appropriate.

7.  Formal Syntax

The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 5234 (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) [RFC5234]. This document extends the via-params to include a new via-alias defined below.

   via-params =/ via-alias
   via-alias  =  "alias"

8.  Normative Behavior

8.1.  Client Behavior

Clients SHOULD 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. Clients, therefore, SHOULD NOT automatically drop connections on completion of a transaction or termination of a dialog.

For TLS transports, the proposed mechanism uses a new Via header field parameter. The "alias" header field parameter is included in a Via header field value to indicate that the client wants to create a transport layer alias. The client places its advertised address in the Via header field value (in the "sent-by" production).

For TCP and SCTP transports, the client SHOULD NOT insert the "alias" header field parameter in the topmost Via header unless conditions mentioned in Section 9.3 (Security Considerations for TCP and SCTP Transports) are duly considered.

If the client places an "alias" header field parameter in the topmost Via header of the request, the client MUST keep the connection open for as long as the resources on the host operating system allow it to, and that the client MUST accept requests over this connection -- in addition to the default listening port -- from its downstream peer. And furthermore, the client SHOULD reuse the connection when subsequent requests in the same or different transactions are destined to the same resolved address.

Note that RFC3261 states that a response arrives over the same connection that was opened for a request.

Whether or not to allow an aliased connection ultimately depends on the recipient of the request; i.e., the client does not get any confirmation that its downstream peer created the alias, or indeed that it even supports this specification. Thus, clients MUST NOT assume that the acceptance of a request by a server automatically enables connection aliasing. Clients MUST continue receiving requests on their default port.

For TLS connections, clients MUST authenticate the connection before forming an alias; Section 9.1 (Authenticating TLS Connections: Client View) discusses the authentication steps in more detail. Once the server has been authenticated, the client MUST cache, in the alias table, the identity (or identities) of the server as they appear in the X.509 certificate subjectAlternativeName extension field. The client MUST also populate the destination IP address, port, and transport of the server in the alias table; these fields are retrieved from executing RFC3263 server resolution process on the next hop URI. And finally, the client MUST populate the alias descriptor field with the socket descriptor used to connect to the server.

Once the alias table has been updated with a resolved address, and the client wants to send a new request in the direction of the server, the client reuses the connection only if all of the following conditions hold:

1. The client uses the RFC3263 resolution on a URI and arrives at a resolved address contained in the alias table, and
2. The URI used for RFC3263 server resolution matches one of the identities stored in the alias table row corresponding to that resolved address.

Clients MUST be prepared for the case that the connection no longer exists when they are ready to send a subsequent request over it. In such a case, a new connection MUST be opened to the resolved address and the alias table updated accordingly.

This behavior has an adverse side effect when a CANCEL request or an ACK request for a non-2xx response is sent downstream. Normally, these would be sent over the same connection that the INVITE request was sent over. However, if between the sending of the INVITE request and subsequent sending of the CANCEL request or ACK request to a non-2xx response, the connection was reclaimed, then the client SHOULD open a new connection to the resolved address and send the CANCEL request or ACK request there instead. The client MAY insert the newly opened connection into the alias table.

8.2.  Server Behavior

Servers SHOULD keep connections up unless they need to reclaim resources. Connection reuse works best when the client and the server maintain their connections for long periods of time. Servers, therefore, SHOULD NOT automatically drop connections on completion of a transaction or termination of a dialog.

The server SHOULD NOT use any TCP connection or SCTP association, which has been accepted at the server, to send requests.

For TCP and SCTP transports, the server SHOULD NOT accord any semantics to the "alias" header field parameter, if present, in the topmost Via header field unless conditions mentioned in Section 9.3 (Security Considerations for TCP and SCTP Transports) are duly considered.

The rest of the discussion below applies to only the TLS transport.

When a server receives a request over TLS whose topmost Via header field contains an "alias" header field parameter, it signifies that the upstream client will leave the connection open beyond the transaction and dialog lifetime, and that subsequent transactions and dialogs that are destined to a resolved address that matches the identifiers in the advertised address in the topmost Via header field can reuse this connection.

Whether or not to use in the reverse direction a connection marked with the "alias" Via header field parameter ultimately depends on the policies of the server. It can choose to honor it, and thereby send subsequent requests over the aliased connection. If the server chooses not to honor an aliased connection, the server MUST allow the request to proceed as though the "alias" header field parameter was not present in the topmost Via header.

This assures interoperability with RFC3261 server behavior. Clients can include the "alias" header field parameter without fear that the server will reject the SIP request because of its presence.

Servers MUST be prepared to deal with the case that the aliased connection no longer exist when they are ready to send a subsequent request over it. This can happen if the peer ran out of operating system resources and had to close the connection. In such a case, the server MUST open a new connection to the resolved address and the alias table updated accordingly.

If the sent-by production of the Via header field contains a port, the server MUST use it as a destination port. Otherwise the default port is the destination port.

Servers SHOULD authenticate the connection before forming an alias. Section 9.2 (Authenticating TLS Connections: Server View) discusses the authentication steps in more detail.

The server, if it decides to reuse the connection, MUST cache in the alias table the identity (or identities) of the client as they appear in the X.509 certificate subjectAlternativeName extension field. The server also populates the destination IP address, port and transport in the alias table from the topmost Via header field (using the ";received" parameter for the destination IP address). If the port number is omitted, a default port number of 5061 is to be used. And finally, the server populates the alias descriptor field with the socket descriptor used to accept the connection from the client (see Section 5 (Overview of Operation) for the contents of the alias table.)

Once the alias table has been updated, and the server wants to send a request in the direction of the client, it reuses the connection only if all of the following conditions hold:

1. The server, which acts as a client for this transaction, uses the RFC3263 resolution process on a URI and arrives at a resolved address contained in the alias table, and
2. The URI used for RFC3263 server resolution matches one of the identities stored in the alias table row corresponding to that resolved address.

9.  Security Considerations

This document presents requirements and a mechanism for reusing existing connections easily. Unauthenticated connection reuse would present many opportunities for rampant abuse and hijacking. Authenticating 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.

9.1.  Authenticating TLS Connections: Client View

When a TLS client establishes a connection with a server, it is presented with the server's X.509 certificate. Authentication proceeds as described in Section 5 of RFC YYYY [I‑D.domain‑certs] (Gurbani, V., Lawrence, S., and A. Jeffrey, “Domain Certificates in the Session Initiation Protocol (SIP),” October 2008.).

Note to RFC Editor: Please replace RFC YYYY with the RFC number assigned to the above reference.

9.2.  Authenticating TLS Connections: Server View

A TLS server conformant to this specification MUST ask for a client certificate; if the client possesses a certificate, it will be presented to the server for mutual authentication, and authentication proceeds as described in Section 6 of RFC YYYY [I‑D.domain‑certs] (Gurbani, V., Lawrence, S., and A. Jeffrey, “Domain Certificates in the Session Initiation Protocol (SIP),” October 2008.).

Note to RFC Editor: Please replace RFC YYYY with the RFC number assigned to the above reference.

If the client does not present a certificate, the server MUST proceed as if the "alias" header field parameter was not present in the topmost Via header. In this case, the server MUST NOT update the alias table.

9.3.  Security Considerations for TCP and SCTP Transports

Clients SHOULD NOT reuse TCP connections or SCTP associations using the same mechanism to reuse TLS connections because there isn't any way to perform the authentication step.

Connection reuse over TCP or SCTP is inherently insecure. Without the X.509 certificate-based proof of identity when using TLS between communicating peers, the mechanisms defined in this document can enable a rogue host to represent a legitimate domain's proxy simply by populating the topmost Via header field sent-by production rule with a legitimate domain name. As an example, consider a proxy that receives a request with the following topmost Via header field (the "received" header field parameter is added by the proxy after getting the request):

Via: SIP/2.0/TCP p1.example.com;branch=z9hG4bKa7c8dze;alias;
   received=192.0.2.100

The proxy has no authoritative means of asserting that the sender of this request can indeed be trusted to belong to the example.com domain; all it has is the information in the advertised address. If it attempts to reuse this connection, requests that would normally go to the example.com domain would now instead be destined to 192.0.2.100, which can in fact be a rogue host that has no affiliation with the example.com domain.

For this reason, connection reuse over TCP and SCTP is NOT RECOMMENDED unless the server-end of the connection has some way of verifying the identity of the client-end of the connection to the same level of assurance as it would have by doing a DNS lookup and establishing a connection in the backwards direction. For example, if a DNS lookup resolved to the same address and port as the source address and source port of the inbound connection, then this level of assurance can be acceptable.

If the server-end of the connection does not have any manner of verifying the identity of the client-end, then it actively opens up a connection in the direction of its peer using RFC3263 server selection process. This connection can be used as a persistent connection for requests going in the backwards direction. Thus the two peers will open and maintain a connection in the direction of the other (as depicted in Figure 2 (Two connections for requests between A and B.)). This manner of opening connections, while still not secure, is at least more secure than using the connection reuse mechanism over TCP or SCTP in an unauthenticated fashion.

10.  Connection reuse and Virtual servers

Virtual servers present special considerations for connection reuse. Under the name-based virtual server scheme, one SIP proxy can host many virtual domains using one IP address and port number. If adequate defenses are not put in place, a connection opened to a downstream server on behalf of one domain can be reused to send requests in the backwards direction to a different domain. The Destination Identity column in the alias table has been added to aid in such defenses.

Virtual servers MUST only perform connection reuse for TLS connections; virtual servers MUST NOT perform connection reuse for other connection-oriented transports. To understand why this is the case, note that the alias table caches not only which connections go to which destination addresses, but also which connections have authenticated themselves as responsible for which domains. If a message is to be sent in the backwards direction to a new SIP domain that resolves to an address with a cached connection, the cached connection cannot be used because it is not authenticated for the new domain.

As an example, consider a proxy P1 that hosts two virtual domains -- example.com and example.net -- on the same IP address and port. RFC3263 server resolution is set up such that a DNS lookup of example.com and example.net both resolve to an {IP-address, port, transport} tuple of {192.0.2.1, 5061, TLS}. A user agent in the example.com domain sends a request to P1 causing it to make a downstream connection to its peering proxy, P2, and authenticating itself as a proxy in the example.com domain by sending it a X.509 certificate asserting such an identity. P2's alias table now looks like the following:

Destination  Destination  Destination  Destination     Alias
IP Address   Port         Transport    Identity        Descriptor
...
192.0.2.1    5061             TLS      sip:example.com     18

At some later point in time, a user agent in P2's domain wants to send a request to a user agent in the example.net domain. P2 performs a RFC3263 server resolution process on sips:example.net to derive a resolved address tuple {192.0.2.1, 5061, TLS}. It appears that a connection to this network address is already cached in the alias table, however, P2 cannot reuse this connection because the destination identity (sip:example.com) does not match the server identity used for RFC3261 resolution (sips:example.net). Hence, P2 will open up a new connection to the example.net virtual domain hosted on P1. P2's alias table will now look like:

Destination  Destination  Destination  Destination     Alias
IP Address   Port         Transport    Identity        Descriptor
...
192.0.2.1    5061             TLS      sip:example.com     18
192.0.2.1    5061             TLS      sip:example.net     54

The identities conveyed in an X.509 certificate are associated with a specific TLS connection. Absent such a guarantee of an identity tied to a specific connection, a normal TCP or SCTP connection cannot be used to send requests in the backwards direction without a significant risk of inadvertent (or otherwise) connection hijacking.

11.  Connection Reuse and SRV Interaction

Connection reuse has an interaction with the DNS SRV load balancing mechanism. To understand the interaction, consider the following figure:

          /+---- S1
+-------+/
| Proxy |------- S2
+-------+\
          \+---- S3

Here, the proxy uses DNS SRV to load balance across the three servers, S1, S2, and S3. Using the connect reuse mechanism specified in this document, over time the proxy will maintain a distinct aliased connection to each of the servers. However, once this is done, subsequent traffic is load balanced across the three downstream servers in the normal manner.

12.  IANA Considerations

This specification defines a new Via header field parameter called "alias" in the "Header Field Parameters and Parameter Values" sub-registry as per the registry created by RFC 3968 [RFC3968] (Camarillo, G., “The Internet Assigned Numbers Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP),” December 2004.). The required information is:

Header Field  Parameter Name  Predefined Values  Reference
___________________________________________________________________
Via           alias                 No           RFCXXXX

RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC number of
this specification.]

13.  Acknowledgments

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. Other members of the SIP WG that contributed to this document include Jeroen van Bemmel, Keith Drage, Matthew Gardiner, Rajnish Jain, Benny Prijono, and Rocky Wang.

Dale Worley and Hadriel Kaplan graciously performed a WGLC review of the draft. The resulting revision has benefited tremendously from their feedback.

14.  References

14.1. Normative References

14.2. Informational References

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2008).

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, THE IETF TRUST 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.