From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5923.txt | 1067 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1067 insertions(+) create mode 100644 doc/rfc/rfc5923.txt (limited to 'doc/rfc/rfc5923.txt') diff --git a/doc/rfc/rfc5923.txt b/doc/rfc/rfc5923.txt new file mode 100644 index 0000000..570c3a1 --- /dev/null +++ b/doc/rfc/rfc5923.txt @@ -0,0 +1,1067 @@ + + + + + + +Internet Engineering Task Force (IETF) V. Gurbani, Ed. +Request for Comments: 5923 Bell Laboratories, Alcatel-Lucent +Category: Standards Track R. Mahy +ISSN: 2070-1721 Unaffiliated + B. Tate + BroadSoft + June 2010 + + + Connection Reuse in the Session Initiation Protocol (SIP) + +Abstract + + This document enables a pair of communicating proxies to reuse a + congestion-controlled connection between themselves for sending + requests in the forwards 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 Transport + Layer Security (TLS). For this reason, we only consider connection + reuse for TLS over TCP and TLS over Stream Control Transmission + Protocol (SCTP). This document also provides guidelines on + connection reuse and virtual SIP servers and the interaction of + connection reuse and DNS SRV lookups in SIP. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5923. + + + + + + + + + + + + + +Gurbani, et al. Standards Track [Page 1] + +RFC 5923 SIP Connection Reuse June 2010 + + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ...................................................3 + 2. Terminology ....................................................4 + 3. Applicability Statement ........................................5 + 4. Benefits of TLS Connection Reuse ...............................5 + 5. Overview of Operation ..........................................6 + 6. Requirements ..................................................10 + 7. Formal Syntax .................................................11 + 8. Normative Behavior ............................................11 + 8.1. Client Behavior ...........................................11 + 8.2. Server Behavior ...........................................13 + 8.3. Closing a TLS Connection ..................................14 + 9. Security Considerations .......................................14 + 9.1. Authenticating TLS Connections: Client View ...............14 + 9.2. Authenticating TLS Connections: Server View ...............15 + 9.3. Connection Reuse and Virtual Servers ......................15 + 10. Connection Reuse and SRV Interaction ..........................17 + 11. IANA Considerations ...........................................17 + 12. Acknowledgments ...............................................17 + 13. References ....................................................18 + 13.1. Normative References ......................................18 + 13.2. Informative References ....................................18 + + + + + + + + + + + + + +Gurbani, et al. Standards Track [Page 2] + +RFC 5923 SIP Connection Reuse June 2010 + + +1. Introduction + + SIP entities can communicate using either unreliable/connectionless + (e.g., UDP) or reliable/connection-oriented (e.g., TCP, SCTP + [RFC4960]) 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 49160) for a new connection to B. These + entities could be SIP user agents or SIP proxy servers. + + +-----------+ 49160 (UAC) 5061 (UAS) +-----------+ + | |--------------------------->| | + | Entity | | Entity | + | A | | B | + | | 5061 (UAS) | | + +-----------+ +-----------+ + + Figure 1: Uni-directional connection for requests from A to B + + The SIP protocol includes the notion of a persistent connection + (defined in Section 2), 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. + + +-----------+ 49160 5061 +-----------+ + | |.......................>| | + | Entity | | Entity | + | A | 5061 49170 | B | + | |<-----------------------| | + +-----------+ +-----------+ + + Figure 2: Two connections for requests between A and B + + Unlike 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 except that A and B both use a single shared connection, for + + + + +Gurbani, et al. Standards Track [Page 3] + +RFC 5923 SIP Connection Reuse June 2010 + + + example, between port 49160 on A and port 5061 on B. 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. + +2. 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 [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: Reusing an existing connection to send 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 RFC 3261 [RFC3261]. 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 + RFC 3263 [RFC3263] on a Uniform Resource Identifier (URI). + + Shared connection: See "Persistent connection". + + + + + + + + + + + + + +Gurbani, et al. Standards Track [Page 4] + +RFC 5923 SIP Connection Reuse June 2010 + + +3. 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 [RFC5626]. + + This memo concerns connection reuse, not persistent connections (see + definitions of these in Section 2). Behavior for persistent + connections is specified in Section 18 of RFC 3261 [RFC3261] 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 [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). + +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]). + + 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. + + + + + + + + + + + + + + + +Gurbani, et al. Standards Track [Page 5] + +RFC 5923 SIP Connection Reuse June 2010 + + + Proxy A Proxy B + | | + Create connection 1 +---INV--->| + | | + |<---200---+ Response over connection 1 + | | + Reuse connection 1 +---ACK--->| + | | + = = + | | + |<---BYE---+ Create connection 2 + | | + Response over +---200--->| + connection 2 + + Figure 3: Multiple connections for requests + + 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 4 in RFC 3725 [RFC3725] uses many + re-INVITE 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. + + + + + + + + +Gurbani, et al. Standards Track [Page 6] + +RFC 5923 SIP Connection Reuse June 2010 + + + 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 User Agent Client (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). + + 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 + + Figure 4: Proxy setup + + 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, 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. + + + + +Gurbani, et al. Standards Track [Page 7] + +RFC 5923 SIP Connection Reuse June 2010 + + + 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] 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). 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 the + 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). + + + + + +Gurbani, et al. Standards Track [Page 8] + +RFC 5923 SIP Connection Reuse June 2010 + + + 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) 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. + + + + + + +Gurbani, et al. Standards Track [Page 9] + +RFC 5923 SIP Connection Reuse June 2010 + + + 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). + + 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. + + + +Gurbani, et al. Standards Track [Page 10] + +RFC 5923 SIP Connection Reuse June 2010 + + + 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 [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. + + The mechanism for connection reuse 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). + + If the client places an "alias" header field parameter in the topmost + Via header of the request, the client SHOULD 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 RFC 3261 states that a response arrives over the same + connection that was opened for a request. + + + + + + + + +Gurbani, et al. Standards Track [Page 11] + +RFC 5923 SIP Connection Reuse June 2010 + + + 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. + + Clients MUST authenticate the connection before forming an alias; + Section 9.1 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 determined + in Section 7.1 of RFC 5922 [RFC5922]. 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 connection handle (or + identifier) 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 over which the INVITE + request was sent. 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 closed, 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. + + + + + + +Gurbani, et al. Standards Track [Page 12] + +RFC 5923 SIP Connection Reuse June 2010 + + +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. + + 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 MUST follow the authentication steps outlined in Section 9.2 + to authenticate the connection before forming an alias. + + 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 + + + +Gurbani, et al. Standards Track [Page 13] + +RFC 5923 SIP Connection Reuse June 2010 + + + ";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 + connection handle (or identifier) used to accept the connection from + the client (see Section 5 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. + +8.3. Closing a TLS connection + + Either the client or the server may terminate a TLS session by + sending a TLS closure alert. Before closing a TLS connection, the + initiator of the closure MUST either wait for any outstanding SIP + transactions to complete, or explicitly abandon them. + + After the initiator of the close has sent a closure alert, it MUST + discard any TLS messages until it has received a similar alert from + its peer. The receiver of the closure alert MUST NOT start any new + SIP transactions after the receipt of the closure alert. + +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 7.3 ("Client behavior") of RFC 5922 + [RFC5922]. + + + + + +Gurbani, et al. Standards Track [Page 14] + +RFC 5923 SIP Connection Reuse June 2010 + + +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 7.4 ("Server behavior") of RFC 5922 + [RFC5922]. + + 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. 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: + + + + + + +Gurbani, et al. Standards Track [Page 15] + +RFC 5923 SIP Connection Reuse June 2010 + + + 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 an 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. + + The above discussion details the impact on P2 when connection reuse + is desired for virtual servers. There is a subtle, but important + impact on P1 as well. + + P1 should keep separate alias tables for the requests served from the + UAs in the example.com domain from those served by the UAs in the + example.net domain. This is so that the boundary between the two + domains is preserved; P1 MUST NOT open a connection on behalf of one + domain and reuse it to send a new request on behalf of another + domain. + + + + + + + + + + + + + +Gurbani, et al. Standards Track [Page 16] + +RFC 5923 SIP Connection Reuse June 2010 + + +10. 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 + + Figure 5: Load balancing + + Here, the proxy uses the 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. + +11. 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]. The + required information is: + + Header Field Parameter Name Predefined Values Reference + ___________________________________________________________________ + Via alias No RFC5923 + +12. 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 document. The resulting revision has benefited tremendously from + their feedback. + + + + + + + +Gurbani, et al. Standards Track [Page 17] + +RFC 5923 SIP Connection Reuse June 2010 + + +13. References + +13.1. Normative References + + [RFC3261] 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. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation + Protocol (SIP): Locating SIP Servers", RFC 3263, + June 2002. + + [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 5234, January 2008. + + [RFC5922] Gurbani, V., Lawrence, S., and B. Laboratories, "Domain + Certificates in the Session Initiation Protocol (SIP)", + RFC 5922, June 2010. + +13.2. Informative References + + [RFC3968] Camarillo, G., "The Internet Assigned Number Authority + (IANA) Header Field Parameter Registry for the Session + Initiation Protocol (SIP)", BCP 98, RFC 3968, + December 2004. + + [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- + Initiated Connections in the Session Initiation Protocol + (SIP)", RFC 5626, October 2009. + + [Book-Rescorla-TLS] + Rescorla, E., "SSL and TLS: Designing and Building Secure + Systems", Addison-Wesley Publishing, 2001. + + [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)", + BCP 85, RFC 3725, April 2004. + + [RFC4960] Stewart, R., "Stream Control Transmission Protocol", + RFC 4960, September 2007. + + + +Gurbani, et al. Standards Track [Page 18] + +RFC 5923 SIP Connection Reuse June 2010 + + +Authors' Addresses + + Vijay K. Gurbani (editor) + Bell Laboratories, Alcatel-Lucent + + EMail: vkg@alcatel-lucent.com + + + Rohan Mahy + Unaffiliated + + EMail: rohan@ekabal.com + + + Brett Tate + BroadSoft + + EMail: brett@broadsoft.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gurbani, et al. Standards Track [Page 19] + -- cgit v1.2.3