One document matched: draft-ietf-sip-connect-reuse-09.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<rfc docName="DOCNAME"
category= "std"
ipr="full3978"
updates="3261">
<front>
<title abbrev="SIP Connection Reuse">
Connection Reuse in the Session Initiation Protocol (SIP)
</title>
<author initials="R." surname="Mahy" fullname="Rohan Mahy">
<organization>Plantronics</organization>
<address>
<postal/>
<email>rohan@ekabal.com</email>
</address>
</author>
<author initials="V." surname="Gurbani" fullname="Vijay K. Gurbani"
role="editor">
<organization>Bell Laboratories, Alcatel-Lucent</organization>
<address>
<postal/>
<email>vkg@alcatel-lucent.com</email>
</address>
</author>
<author initials="B." surname="Tate" fullname="Brett Tate">
<organization>BroadSoft</organization>
<address>
<postal/>
<email>brett@broadsoft.com</email>
</address>
</author>
<date month="MONTH" year="YEAR" />
<area>Transport</area>
<workgroup>SIP WG</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>connection reuse</keyword>
<abstract>
<t>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
should be 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. A
single connection cannot be reused for the TCP or SCTP transport between
two peers, and this document provides insight 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.</t>
</abstract>
</front>
<middle>
<section title="Terminology" anchor="terminology">
<t>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
<xref target="RFC2119">RFC 2119</xref>.</t>
<t>Additional terminology used in this document:</t>
<t>
<list style="hanging">
<t hangText="Advertised address:">The address that occurs in the
Via sent-by production rule, including the port number and transport.</t>
<t hangText="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.</t>
<t hangText="Connection reuse:">See "Alias".</t>
<t hangText="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 is specified
in Section 18 of RFC3261 <xref target="RFC3261"/>. Persistent
connections do not imply connection reuse.</t>
<t hangText="Resolved address:"> The network identifiers (IP address,
port, transport) associated with a user agent as a result of
executing RFC3263 <xref target="RFC3263"/> on a Uniform Resource
Identifier (URI).</t>
<t hangText="Shared connection:">See "Persistent connection."</t>
</list>
</t>
</section>
<section title="Applicability Statement">
<t>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
<xref target="I-D.ietf-sip-outbound"></xref>.</t>
<t>This memo concerns connection reuse, not persistent connections
(see definitions of these in <xref target="terminology"/>). Behavior
for persistent connections is specified in Section 18 of RFC3261
<xref target="RFC3261"/> and is not altered by this memo.</t>
<t>This memo RECOMMENDS that only those connections be reused where the
identity of the sender can be verified by the receiver. Thus, TLS
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
<xref target="overview"/>). For reasons discussed in
<xref target="auth-tcp"/>, connection reuse over other connection-oriented
transport (TCP, <xref target="RFC2960">SCTP</xref>) is NOT RECOMMENDED.</t>
</section>
<section title="Introduction">
<t><xref target="RFC3261">SIP</xref> entities can communicate using either
unreliable/connectionless (e.g., UDP) or reliable/connection-oriented
(e.g., TCP, <xref target="RFC2960">SCTP</xref>) 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.</t>
<t>In the following example, A listens for SIP requests over
<xref target="RFC2246">TLS</xref> 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.</t>
<figure title="Uni-directional connection for requests from A to B"
anchor="uni-dir">
<artwork><![CDATA[
+-----------+ 8293 (UAC) 5061 (UAS) +-----------+
| |--------------------------->| |
| Entity | | Entity |
| A | | B |
| | 5061 (UAS) | |
+-----------+ +-----------+
]]></artwork></figure>
<t>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.</t>
<figure title="Two connections for requests between A and B."
anchor="two-conns">
<artwork><![CDATA[
+-----------+ 8293 5061 +-----------+
| |.......................>| |
| Entity | | Entity |
| A | 5061 9741 | B |
| |<-----------------------| |
+-----------+ +-----------+
]]></artwork></figure>
<t>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 <xref target="uni-dir"/> 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.</t>
</section>
<section title="Benefits of TLS Connection Reuse">
<t>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 3-way handshake, a handful of round-trips to
establish TLS, typically expensive asymmetric authentication and key
generation algorithms, and certificate verification. This may 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
<xref target="Book-Rescorla-TLS"/>).</t>
<t>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.</t>
<figure title="Multiple connections for requests"
anchor="fig-mult-conns">
<artwork><![CDATA[
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
]]></artwork></figure>
<t>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 or BYE after an initial INVITE, or a NOTIFY after a SUBSCRIBE
<xref target="RFC3265"/> or a REFER <xref target="RFC3515"/>), can also
cause excessive delay (especially in networks with long round-trip times).
Thus, it is advantageous to reuse connections whenever possible.</t>
<t>From the user expectation point of view, it is advantageous if the
re-INVITEs or <xref target="RFC3311">UPDATE</xref> requests are handled
automatically and rapidly in order to avoid media and session state from
being out of step. If a re-INVITE 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 <xref target="RFC3725">RFC3725</xref> use many reINVITEs).</t>
<t>The mechanism described in this document can mitigate the delays
associated with subsequent requests.</t>
</section>
<section title="Overview of Operation" anchor="overview">
<t>This section is tutorial in nature, and does not specify any normative
behavior.</t>
<t>We now explain this working in more detail in the context of
communication between two adjacent proxies. Without any loss of generality,
it should be clear that 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.</t>
<t>P1 and P2 are proxies responsible for routing SIP requests to
user agents that use them as edge proxies
(see <xref target="fig-proxy-setup"/>).</t>
<figure title="Proxy setup"
anchor="fig-proxy-setup">
<artwork><![CDATA[
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
]]></artwork></figure>
<t>For illustration purpose the discussion below uses TCP as a transport
for TLS operations. Another streaming transport -- such as SCTP
<xref target="RFC2960"/> -- can be used as well.</t>
<t>The act of reusing a connection is initiated by P1 when it adds
an "alias" parameter (defined later) to the Via header. When P2 receives
the request, it examines the topmost Via header. If the header
contained an "alias" 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.</t>
<t>With reference to <xref target="fig-proxy-setup"/>, in order for
P2 to reuse a connection for requests in the backwards direction, it is
important to note that the validation model for requests sent in
this direction (i.e., P2 to P1) should be 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 must have 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 must be
cached for later use.</t>
<t>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.</t>
<t>P1 gets a request from one of its upstream user agents, and after
performing 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" parameter to the topmost
Via header (inserted by it) before sending the request to P2. The
value in the sent-by production rule of the Via header (including the
port number), and the transport over which the request was sent becomes
the advertised address of P1:</t>
<t>Via: SIP/2.0/TLS p1.example.com;branch=z9hG4bKa7c8dze;alias</t>
<t>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 <xref target="auth-tls-client"/>).
Upon connection authentication and acceptance, P1 adds P2 to its
alias table. P1's alias table now looks like:</t>
<artwork><![CDATA[
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
]]></artwork>
<t>Subsequent requests that traverse from P1 to P2 will reuse this
connection; i.e., the requests will be sent over the descriptor 25.</t>
<t>The following columns in the alias table created at the client
warrant an explanation:</t>
<list style="numbers">
<t>The IP address, port and transport are a result of executing
RFC3263 server resolution process on a next hop URI.</t>
<t>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 <xref target="auth-tls-client"/>).</t>
<t>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:</t>
<list style="letters">
<t>P1 determines through RFC3263 server resolution process that the
{transport, IP-address, port} tuple of P2 to be {TLS, 192.0.2.128, 5061},
and </t>
<t>The URI used for RFC3263 server resolution matches one of the
identities stored in the cached certificate (fourth column).</t>
</list>
</list>
<t>When P2 receives the request it examines the topmost Via
to determine whether P1 is willing to use this connection as an aliased
connection (i.e., accept requests from P2 towards P1.) The Via at P2 now
looks like the following (the "received" parameter is added by P2):</t>
<artwork><![CDATA[
Via: SIP/2.0/TLS p1.example.com;branch=z9hG4bKa7c8dze;alias;
received=192.0.2.1
]]></artwork>
<t>The presence of the "alias" parameter indicates that P1 supports
aliasing on this connection. P2 now authenticates the connection
(see <xref target="auth-tls-server"/>) and if the authentication was
successful, P2 creates an alias to P1 using the advertised address in
the topmost Via. P2's alias table looks like the following:</t>
<artwork><![CDATA[
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
]]></artwork>
<t>There are a few items of interest here:</t>
<list style="numbers">
<t>The IP address field is populated with the source address of
the client.</t>
<t>The port field is populated from the advertised address (topmost
Via header), if a port is present in it, or 5061 if it is not.</t>
<t>The transport field is populated from the advertised address (topmost
Via header).</t>
<t>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 <xref target="auth-tls-server"/>).</t>
<t>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:</t>
<list style="letters">
<t>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 </t>
<t>The URI used for RFC3263 server resolution matches one of the
identities stored in the cached certificate (fourth column).</t>
</list>
<t>The network address inserted in the "Destination IP Address" column should
be the source address as seen by P2 (i.e., the "received" 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.</t>
</list>
</section> <!-- overview -->
<section title="Requirements">
<t>The following are the requirements that motivated this specification:</t>
<t><list style="numbers">
<t>A connection sharing mechanism SHOULD allow SIP entities to reuse existing
connections for requests and responses originated from either peer in the
connection.</t>
<t>A connection sharing mechanism MUST NOT require clients to send
all traffic from well-know SIP ports.</t>
<t>A connection sharing mechanism MUST NOT require configuring ephemeral port
numbers in DNS.</t>
<t>A connection sharing mechanism MUST prevent unauthorized hijacking of
other connections.</t>
<t>Connection sharing SHOULD persist across SIP transactions and dialogs.</t>
<t>Connection sharing MUST work across name-based virtual SIP servers.</t>
<t>There is no requirement to share a complete path for ordinary connection
reuse. Hop-by-hop connection sharing is more appropriate.</t>
</list>
</t>
</section>
<section title="Formal Syntax">
<t>The following syntax specification uses the augmented Backus-Naur Form (BNF)
as described in <xref target="RFC5234">RFC 5234</xref>. This document
extends the via-params to include a new via-alias defined below.</t>
<artwork>
via-params =/ via-alias
via-alias = "alias"
</artwork>
</section>
<section title="Normative Behavior">
<t>This document specifies how to reuse connections. It is
RECOMMENDED 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
automatically drop connections on completion of a transaction or
termination of a dialog.</t>
<!--
<t>When this document is followed to specify connection reuse, an alias
is formed at the receiver of a request when it gets a request
with the "alias" parameter in the topmost Via header. If the receiver
decides to accept the alias, then the alias corresponds to the source IP
address, transport, port (if one exists in the Via sent-by, or the default
port if it does not), and the identities of the sender as asserted in
the certificate of the sender of the request. Whenever the RFC3263
server selection mechanism executed at the receiver results in the
choice of this IP address, port, transport, and identity tuple, the
alias SHOULD be used instead.</t>
<t><list>
<t>Note that at the receiver, the responses are sent over the same
connection as specified by RFC3261. The aliasing mechanism at the
receiver allows subsequent requests going from the receiver to the original
sender of the request to reuse the same connection.</t>
</list></t>
<t>An alias is formed at the sender of the request when it executes the
RFC3263 server selection mechanism to arrive at an IP address, port,
and transport tuple to send a request to. Subsequent requests going to
the same resolved address SHOULD use the alias instead.</t>
-->
<t>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.</t>
<t><list style="empty">
<t>Note that 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 and subsequent sending of the CANCEL or ACK 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 or ACK
there instead. The newly opened connection MAY be inserted into the
alias table.</t>
</list></t>
<section title="Client Behavior">
<t>For TLS transports, 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 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).
<t><list style="empty">
<t>For TCP and SCTP transports, the client MUST NOT insert the "alias"
parameter in the topmost Via header.</t>
</list></t>
</t>
<t>If the client places an "alias" 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 it
MUST accept requests over this connection -- in addition to the default
listening port -- from its downstream peer. And furthermore, it SHOULD
reuse the connection when subsequent requests in the same or different
transactions are destined to the same resolved address.</t>
<t><list>
<t>Note that RFC3261 states that a response should arrive over the same
connection that was opened for a request.</t>
</list></t>
<t>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. They
MUST continue receiving requests on their default port.</t>
<t>For TLS connections, clients MUST authenticate the connection before
forming an alias; <xref target="auth-tls-client"/> 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.</t>
<t>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,
it should reuse the connection only if all of the following conditions
hold:</t>
<list style="numbers">
<t>The client uses the RFC3263 resolution on a URI and arrives at a
resolved address contained in the alias table, and</t>
<t>The URI used for RFC3263 server resolution matches one of the
identities stored in the alias table row corresponding to that resolved
address.</t>
</list>
</section>
<section title="Server Behavior">
<t>A TCP connection, or a SCTP association accepted at the server is
used by the server to only send responses upstream. It SHOULD NOT be used
to send requests. Furthermore, if the topmost Via header of a request
received over TCP or SCTP had an "alias" parameter in it, the server
MUST NOT accord any semantics to this parameter and must behave as
if the parameter was not present.</t>
<t>The rest of the discussion below applies to only the TLS transport.</t>
<t>When a server receives a request over TLS whose topmost Via header
contains an "alias" 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 can reuse this connection. </t>
<t>Whether or not to use in the reverse direction a connection marked with
"alias" ultimately depends on the policies of the server. It may choose
to honor it, and thereby send subsequent requests over the aliased
connection. If the server chooses not to honor an aliased connection, it
MUST allow the request to proceed as though the "alias" parameter was
not present in the topmost Via header.</t>
<t><list>
<t>This assures interoperability with RFC3261 server behavior. Clients
should feel comfortable including the "alias" parameter without
fear that the server will reject the SIP request because of its
presence.</t>
</list></t>
<t>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 may happen if the peer ran out of operating system
resources and had to close the connection. In such a case, a new connection
MUST be opened to the resolved address and the alias table updated
accordingly.</t>
<t>If the Via sent-by contains a port, it MUST be used as a destination
port. Otherwise the default port is the destination port.</t>
<t>Servers must authenticate the connection before forming an alias.
<xref target="auth-tls-server"/> discusses the authentication steps
in more detail. </t>
<t>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 must also populate the destination IP address, port and
transport in the alias table from the topmost Via header (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 must populate the alias descriptor field with the
socket descriptor used to accept the connection from the client (see
<xref target="overview"/> for the contents of the alias table.)</t>
<t>Once the alias table has been updated, and the server wants to
send a request in the direction of the client, it should reuse
the connection only if all of the following conditions hold:</t>
<list style="numbers">
<t>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</t>
<t>The URI used for RFC3263 server resolution matches one of the
identities stored in the alias table row corresponding to that
resolved address.</t>
</list>
</section>
</section> <!-- Normative Behavior -->
<section anchor="auth" title="Security Considerations">
<t>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.</t>
<section title="Authenticating TLS Connections: Client View"
anchor="auth-tls-client">
<t>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 <xref target="I-D.domain-certs"/>.</t>
</section>
<section title="Authenticating TLS Connections: Server View"
anchor="auth-tls-server">
<t>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 <xref target="I-D.domain-certs"/>.</t>
<t>If the client does not present a certificate, the server MUST
proceed as if the "alias" parameter was not present in the topmost
Via. In this case, the alias table MUST NOT be updated.</t>
</section>
<section title="Security Considerations for TCP and SCTP Transports"
anchor="auth-tcp">
<t>The mechanism for reusing TLS connections SHOULD NOT be used to
reuse TCP connections or SCTP associations because there isn't any way
to perform the authentication step.</t>
<t>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 memo may enable
a rogue host to represent a legitimate domain's proxy simply by populating
the topmost Via 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 (the "received" parameter is added by the proxy after
getting the request):</t>
<artwork>
Via: SIP/2.0/TCP p1.example.com;branch=z9hG4bKa7c8dze;
received=192.0.4.33
</artwork>
<t>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.4.33,
which may in fact be a rogue host that has no affiliation with the
example.com domain.</t>
<t>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 may
be acceptable.</t>
<t>If the server-end of the connection does not have any manner of
verifying the identity of the client-end, then it should actively
open 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 <xref target="two-conns"/>). 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.</t>
</section>
</section>
<section title="Connection reuse and Virtual servers" anchor="virt-server">
<t>Virtual servers present special considerations for connection
reuse. Under the name-based virtual server scheme, one SIP proxy
may 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 may 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.</t>
<t>Connection reuse in a virtual server MUST only be done for
TLS connections, all other connection-oriented transports MUST NOT
reuse connections. To understand why this is the case, note that
the alias table must cache 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.</t>
<t>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:</t>
<artwork><![CDATA[
Destination Destination Destination Destination Alias
IP Address Port Transport Identity Descriptor
...
192.0.2.1 5061 TLS sip:example.com 18
]]></artwork>
<t>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, note that 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:</t>
<artwork><![CDATA[
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
]]></artwork>
<t>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.</t>
</section> <!-- virt-server -->
<section title="Connection Reuse and SRV Interaction">
<t>Connection reuse has an interaction with the DNS SRV load balancing
mechanism. To understand the interaction, consider the following figure:</t>
<figure title="Load balancing"
anchor="fig-load-balancing">
<artwork>
/+---- S1
+-------+/
| Proxy |------- S2
+-------+\
\+---- S3
</artwork></figure>
<t>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.</t>
</section>
<section title="IANA Considerations">
<t>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 <xref target="RFC3968"/>.
The required information is:</t>
<artwork>
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.]
</artwork>
</section>
<section title= "Acknowledgments" >
<t>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.</t>
<t>Dale Worley and Hadriel Kaplan graciously performed a WGLC review of
the draft. The resulting revision has benefited tremendously from
their feedback.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC3261">
<front>
<title>SIP: Session Initiation Protocol</title>
<author initials="J." surname="Rosenberg"/>
<author initials="H." surname="Schulzrinne"/>
<author initials='G.' surname='Camarillo'/>
<author initials='A.' surname='Johnston'/>
<author initials='J.' surname='Peterson'/>
<author initials='R.' surname='Sparks'/>
<author initials='M.' surname='Handley'/>
<author initials='E.' surname='Schooler'/>
<date month="June" year="2002"/>
</front>
<seriesInfo name="RFC" value="3261"/>
<format type="TXT" target="http://www.ietf.org/rfc/rfc3261.txt"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner">
<organization></organization>
</author>
<date month="March" year="1997"/>
</front>
<seriesInfo name="RFC" value="2119"/>
<format type="TXT" target="http://www.ietf.org/rfc/rfc2119.txt"/>
</reference>
<reference anchor="RFC2246">
<front>
<title>The TLS Protocol Version 1.0</title>
<author initials="T." surname="Dierks"/>
<author initials="C." surname="Allen"/>
<date month="January" year="1999"/>
</front>
<seriesInfo name="RFC" value="2246"/>
<format type="TXT" target="http://www.ietf.org/rfc/rfc2246.txt"/>
</reference>
<reference anchor="RFC3263">
<front>
<title>Session Initiation Protocol (SIP): Locating SIP Servers</title>
<author initials="J." surname="Rosenberg"/>
<author initials="H." surname="Schulzrinne"/>
<date month="June" year="2002"/>
</front>
<seriesInfo name="RFC" value="3263"/>
<format type="TXT" target="http://www.ietf.org/rfc/rfc3263.txt"/>
</reference>
<reference anchor='RFC5234'>
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author initials='D.H.' surname='Crocker'></author>
<author initials='P.' surname='Overell'></author>
<date month='January' year='2008' />
</front>
<seriesInfo name='RFC' value='5234' />
<format type="TXT" target="http://www.ietf.org/rfc/rfc5234.txt"/>
</reference>
<reference anchor='RFC3968'>
<front>
<title>The Internet Assigned Numbers Authority (IANA) Header
Field Paramater Registry for the Session Initiation Protocol (SIP)
</title>
<author initials="G." surname="Camarillo"></author>
<date month="December" year="2004" />
</front>
<seriesInfo name="BCP" value="98"/>
<seriesInfo name="RFC" value="3968" />
<format type="TXT" target="http://www.ietf.org/rfc/rfc3968.txt"/>
</reference>
<reference anchor="I-D.domain-certs">
<front>
<title>Domain Certificates in the Session Initiation Protocol (SIP)</title>
<author initials="V.K" surname="Gurbani"></author>
<author initials="S." surname="Lawrence"></author>
<author initials="A." surname="Jeffrey"></author>
<date month="July" year="2007" />
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-sip-domain-certs-00"/>
<format type="TXT"
target="http://www.ietf.org/internet-drafts/draft-ietf-sip-domain-certs-06.txt"/>
</reference>
</references>
<references title="Informational References">
<reference anchor="I-D.ietf-sip-outbound">
<front>
<title>Managing Client Initiated Connections in the Session Initiation
Protocol (SIP)</title>
<author initials="C." surname="Jennings"/>
<author initials="R." surname="Mahy"/>
<date month="November" year="2007"/>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-sip-outbound-11.txt"/>
<format type="TXT"
target="http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-11.txt"/>
</reference>
<reference anchor="Book-Rescorla-TLS">
<front>
<title>SSL and TLS: Designing and Building Secure Systems</title>
<author initials="E." surname="Rescorla"></author>
<date year="2001"/>
</front>
<seriesInfo name="Addison-Wesley Publishing" value=""/>
</reference>
<reference anchor="RFC3311">
<front>
<title>The Session Initiation Protocol (SIP) UPDATE Method</title>
<author initials="J." surname="Rosenberg"></author>
<date month="September" year="2002" />
</front>
<seriesInfo name="RFC" value="3311" />
<format type="TXT" target="http://www.ietf.org/rfc/rfc3311.txt"/>
</reference>
<reference anchor="RFC3725">
<front>
<title>Best Current Practices for Third Party Call Control (3pcc) in the
Session Initiation Protocol (SIP)</title>
<author initials="J." surname="Rosenberg"></author>
<author initials="J." surname="Peterson"></author>
<author initials="H." surname="Schulzrinne"></author>
<author initials="H." surname="Camarillo"></author>
<date month="April" year="2004" />
</front>
<seriesInfo name="RFC" value="3725" />
<format type="TXT" target="http://www.ietf.org/rfc/rfc3725.txt"/>
</reference>
<reference anchor="RFC3515">
<front>
<title>The Session Initiation Protocol (SIP) Refer Method</title>
<author initials="R." surname="Sparks"></author>
<date month="April" year="2003" />
</front>
<seriesInfo name="RFC" value="3515" />
<format type="TXT" target="http://www.ietf.org/rfc/rfc3515.txt"/>
</reference>
<reference anchor="RFC3265">
<front>
<title>The Session Initiation Protocol (SIP)-Specific Event Notification
</title>
<author initials="A." surname="Roach"></author>
<date month="June" year="2002" />
</front>
<seriesInfo name="RFC" value="3265" />
<format type="TXT" target="http://www.ietf.org/rfc/rfc3265.txt"/>
</reference>
<reference anchor="RFC2960">
<front>
<title>The Session Initiation Protocol (SIP)-Specific Event Notification
</title>
<author initials="R." surname="Stewart"></author>
<author initials="Q." surname="Xie"></author>
<author initials="K." surname="Morneault"></author>
<author initials="C." surname="Sharp"></author>
<author initials="H." surname="Schwarzbauer"></author>
<author initials="T." surname="Taylor"></author>
<author initials="I." surname="Rytina"></author>
<author initials="M." surname="Kalla"></author>
<author initials="L." surname="Zhang"></author>
<author initials="V." surname="Paxson"></author>
<date month="October" year="2000" />
</front>
<seriesInfo name="RFC" value="2960" />
<format type="TXT" target="http://www.ietf.org/rfc/rfc2960.txt"/>
</reference>
</references>
</back>
</rfc>
<!--
<section title="Authorizing a cluster of proxies">
<t><list>
<t>NOTE NOTE NOTE NOTE NOTE NOTE: Section maintained for historical
reasons only. Disregard any normative behavior specified in this section.</t>
<t>Editor's note: I am leaving the rest of this section as-is for right now
until we decide what to do with it. The information here addresses a
requirement in the -04 version, which stated that "A connection sharing
mechanism SHOULD allow SIP entities to reuse existing connections with
closely coupled nodes which act as a single SIP entity (for example a
cluster of nodes acting as a proxy server)." That particular requirement
has been removed from the current version since it interacted in a
sub-optimal way with the DNS and SRV load balancing mechanism. However, the
information in this section is helpful and I want to preserve it for
possible use later in a different context. It has the nasty side-effect
that the private key has to be shared across a cluster of proxies...</t>
</list></t>
<t>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.</t>
<figure><artwork><![CDATA[
+------------+
| Proxy |
| A1 |
| | +-----------+
| 10.54.32.1 | | |
+------------+ | Proxy |
+------------+ 8293 5061 | B |
| Proxy |<======================>| |
| A2 | +-----------+
| |
| 10.54.32.2 |
+------------+
]]></artwork></figure>
<t>
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).
</t>
<figure><artwork>
Via: SIP/2.0/TLS proxy-farm-a.example.com;branch=z9hG4bK7c8ze;alias
;received=10.54.32.2
</artwork></figure>
<t>
As a result, this has an important interaction with the DNS resolution mechanisms for SIP described in <xref target="RFC3263">RFC3263</xref>. 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.
</t><t>
Below is a partial DNS zone file for atlanta.com.
</t>
<figure><artwork>
; 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.proxy-farm-a
; 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
</artwork></figure>
<t>
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)
</t><t>
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).
</t>
<t>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 <xref target="RFC3261">SIP</xref> and
<xref target="RFC3263">Locating SIP Servers</xref>.
</t><t>
Following this logic step-by-step:
</t>
<list style="numbers"><t>
Verify that the certificate presented is not expired and is rooted in a trusted certificate chain.
</t><t>
Verify that the subjectAltName in the certificate covers the "advertised address" (the address in the Via sent-by production). If the advertised address and the subjectAltName match exactly then the certificate covers the address.
</t><t>
Use DNS to resolve if the advertised name is resolvable from the subjectAltName (start by resolving the subjectAltName as if it where a target URI according to the rules in RFC3263. That is, if no port number is present perform an SRV lookup, then finally resolve relevant address records). If any of the resolved addresses (port numbers can be ignored in this case) matches the advertised address, then the certificate covers the address.
</t><t>
Finally, verify that the advertised address can resolve to the IP address over which the connection was received.
</t></list>
<t>
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.
</t>
</section>
-->
<!-- LocalWords: xml DOCTYPE rfc dtd stylesheet xsl href xslt toc sortrefs WG
-->
<!-- LocalWords: docName DOCNAME std ipr abbrev Mahy fullname Rohan Gurbani
-->
<!-- LocalWords: Plantronics Vijay Alcatel vkg acm org BroadSoft workgroup IP
-->
<!-- LocalWords: TLS SCTP DNS SRV xref hangText firewalls ietf outbound auth
-->
<!-- LocalWords: tcp connectionless UDP Uni uni dir CDATA UAS conns initially
-->
<!-- LocalWords: Rescorla mult INV ACK INVITEs reINVITE reINVITEs com hG bKa
-->
<!-- LocalWords: dze tls Backus Naur BNF params subjectAlternativeName certs
-->
<!-- LocalWords: interoperability conformant SCP inbound virt IANA RFCXXXX
-->
<!-- LocalWords: XXXX Cullen Jeroen Bemmel Drage Gardiner Rajnish Jain Worley
-->
<!-- LocalWords: Prijono Hadriel WGLC Schulzrinne Camarillo Handley
-->
<!-- LocalWords: seriesInfo
-->
| PAFTECH AB 2003-2026 | 2026-04-23 11:02:16 |