One document matched: draft-ietf-sip-connect-reuse-07.html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>Connection Reuse in the Session Initiation Protocol (SIP)</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="Connection Reuse in the Session Initiation Protocol (SIP)">
<meta name="keywords" content="I-D, Internet-Draft, connection reuse">
<meta name="generator" content="xml2rfc v1.29 (http://xml.resource.org/)">
<style type='text/css'>
<!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
margin: 2em;
font-size: small ; color: #000000 ; background-color: #ffffff ; }
.title { color: #990000; font-size: x-large ;
font-weight: bold; text-align: right;
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
background-color: transparent; }
.filename { color: #666666; font-size: 18px; line-height: 28px;
font-weight: bold; text-align: right;
font-family: helvetica, arial, sans-serif;
background-color: transparent; }
td.rfcbug { background-color: #000000 ; width: 30px ; height: 30px ;
text-align: justify; vertical-align: middle ; padding-top: 2px ; }
td.rfcbug span.RFC { color: #666666; font-weight: bold; text-decoration: none;
background-color: #000000 ;
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-size: x-small ; }
td.rfcbug span.hotText { color: #ffffff; font-weight: normal; text-decoration: none;
text-align: center ;
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-size: x-small ; background-color: #000000; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
div#counter{margin-top: 100px}
a.info{
position:relative; /*this is the key*/
z-index:24;
text-decoration:none}
a.info:hover{z-index:25; background-color:#990000 ; color: #ffffff ;}
a.info span{display: none}
a.info:hover span.info{ /*the span will display just on :hover state*/
display:block;
position:absolute;
font-size: smaller ;
top:2em; left:2em; width:15em;
padding: 2px ;
border:1px solid #333333;
background-color:#eeeeee; color:#990000;
text-align: left ;}
A { font-weight: bold; }
A:link { color: #990000; background-color: transparent ; }
A:visited { color: #333333; background-color: transparent ; }
A:active { color: #333333; background-color: transparent ; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small ; }
p.toc { font-size: small ; font-weight: bold ; margin-left: 3em ;}
span.emph { font-style: italic; }
span.strong { font-weight: bold; }
span.verb, span.vbare { font-family: "Courier New", Courier, monospace ; }
span.vemph { font-style: italic; font-family: "Courier New", Courier, monospace ; }
span.vstrong { font-weight: bold; font-family: "Courier New", Courier, monospace ; }
span.vdeluxe { font-weight: bold; font-style: italic; font-family: "Courier New", Courier, monospace ; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
pre { margin-left: 3em; color: #333333; background-color: transparent;
font-family: "Courier New", Courier, monospace ; font-size: small ;
text-align: left;
}
h3 { color: #333333; font-size: medium ;
font-family: helvetica, arial, sans-serif ;
background-color: transparent; }
h4 { font-size: small; font-family: helvetica, arial, sans-serif ; }
table.bug { width: 30px ; height: 15px ; }
td.bug { color: #ffffff ; background-color: #990000 ;
text-align: center ; width: 30px ; height: 15px ;
}
td.bug A.link2 { color: #ffffff ; font-weight: bold;
text-decoration: none;
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-size: x-small ; background-color: transparent }
td.header { color: #ffffff; font-size: x-small ;
font-family: arial, helvetica, sans-serif; vertical-align: top;
background-color: #666666 ; width: 33% ; }
td.author { font-weight: bold; margin-left: 4em; font-size: x-small ; }
td.author-text { font-size: x-small; }
table.data { vertical-align: top ; border-collapse: collapse ;
border-style: solid solid solid solid ;
border-color: black black black black ;
font-size: small ; text-align: center ; }
table.data th { font-weight: bold ;
border-style: solid solid solid solid ;
border-color: black black black black ; }
table.data td {
border-style: solid solid solid solid ;
border-color: #333333 #333333 #333333 #333333 ; }
hr { height: 1px }
-->
</style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">SIP WG</td><td class="header">R. Mahy</td></tr>
<tr><td class="header">Internet-Draft</td><td class="header">Plantronics</td></tr>
<tr><td class="header">Updates:<a href='ftp://ftp.isi.edu/in-notes/rfc3261.txt'>3261</a> (if approved)</td><td class="header">V. Gurbani, Ed.</td></tr>
<tr><td class="header">Expires: April 9, 2007</td><td class="header">Lucent Technologies, Inc./Bell</td></tr>
<tr><td class="header"> </td><td class="header">Laboratories</td></tr>
<tr><td class="header"> </td><td class="header">B. Tate</td></tr>
<tr><td class="header"> </td><td class="header">BroadSoft</td></tr>
<tr><td class="header"> </td><td class="header">October 6, 2006</td></tr>
</table></td></tr></table>
<div align="right"><span class="title"><br />Connection Reuse in the Session Initiation Protocol (SIP)</span></div>
<div align="right"><span class="title"><br />draft-ietf-sip-connect-reuse-07</span></div>
<h3>Status of this Memo</h3>
<p>
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.</p>
<p>
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.</p>
<p>
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.”</p>
<p>
The list of current Internet-Drafts can be accessed at
<a href='http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/ietf/1id-abstracts.txt</a>.</p>
<p>
The list of Internet-Draft Shadow Directories can be accessed at
<a href='http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html</a>.</p>
<p>
This Internet-Draft will expire on April 9, 2007.</p>
<h3>Copyright Notice</h3>
<p>
Copyright © The Internet Society (2006).</p>
<h3>Abstract</h3>
<p>When SIP entities use a connection oriented protocol to send a request,
they typically originate their connections from an ephemeral port. The
SIP protocol includes mechanisms which ensure that responses to a request,
and new requests sent in the original direction reuse an existing
connection. However, new requests sent in the opposite direction are unlikely
to reuse the existing connection. For TLS transports, this will frequently
cause a pair of SIP entities to use one connection for requests sent in
each direction, resulting in potential scaling and performance problems.
This document proposes that a TLS connection, once opened, can be used to
send requests in either direction. Unfortunately, TCP connections
cannot be shared in the same manner due to the risk of service hijacking.
This document proposes an alternate way to perform TCP connection reuse.
</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#anchor1">1.</a>
Terminology<br />
<a href="#anchor2">2.</a>
Applicability Statement<br />
<a href="#anchor3">3.</a>
Introduction<br />
<a href="#anchor4">4.</a>
Benefits of TLS Connection Reuse<br />
<a href="#overview">5.</a>
Overview of Operation<br />
<a href="#ss-tls-ops">5.1</a>
TLS Operations<br />
<a href="#ss-tcp-ops">5.2</a>
TCP Operations<br />
<a href="#anchor5">6.</a>
Requirements<br />
<a href="#anchor6">7.</a>
Formal Syntax<br />
<a href="#anchor7">8.</a>
Normative Behavior<br />
<a href="#anchor8">8.1</a>
Client Behavior<br />
<a href="#anchor9">8.2</a>
Server Behavior<br />
<a href="#auth">9.</a>
Security Considerations<br />
<a href="#auth-tls-client">9.1</a>
Authenticating TLS Connections: Client View<br />
<a href="#auth-tls-server">9.2</a>
Authenticating TLS Connections: Server View<br />
<a href="#auth-tcp">9.3</a>
Security Considerations for the TCP Transport<br />
<a href="#virt-server">10.</a>
Support for Virtual Servers<br />
<a href="#ss-virt-server-TLS">10.1</a>
Virtual Servers and TLS Connections<br />
<a href="#anchor10">11.</a>
Connection Reuse and SRV Interaction<br />
<a href="#anchor11">12.</a>
IANA Considerations<br />
<a href="#anchor12">13.</a>
Acknowledgments<br />
<a href="#rfc.references1">14.</a>
References<br />
<a href="#rfc.references1">14.1</a>
Normative References<br />
<a href="#rfc.references2">14.2</a>
Informational References<br />
<a href="#rfc.authors">§</a>
Authors' Addresses<br />
<a href="#rfc.copyright">§</a>
Intellectual Property and Copyright Statements<br />
</p>
<br clear="all" />
<a name="anchor1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1. Terminology</h3>
<p>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
<a class="info" href="#RFC2119">RFC 2119<span> (</span><span class="info">Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a>[2].
</p>
<p>Additional terminology used in this document:
</p>
<p>
</p>
<blockquote class="text"><dl>
<dt>Advertised address:</dt>
<dd>The address that occurs in the
Via sent-by production rule, including the port number and transport.
</dd>
<dt>Alias:</dt>
<dd> A transport layer connection associated with a
resolved address.
</dd>
<dt>Resolved address:</dt>
<dd> The network identifiers (IP address,
port, transport) associated with a user agent as a result of
executing RFC3263 <a class="info" href="#RFC3263">[4]<span> (</span><span class="info">Rosenberg, J. and H. Schulzrinne, “Session Initiation Protocol (SIP): Locating SIP Servers,” June 2002.</span><span>)</span></a> on a Uniform Resource
Identifier (URI).
</dd>
</dl></blockquote><p>
</p>
<a name="anchor2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2. Applicability Statement</h3>
<p>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 firewall reasons -- reuse
their connections using the mechanism described in
<a class="info" href="#I-D.ietf-sip-outbound">[8]<span> (</span><span class="info">Jennings, C. and R. Mahy, “Managing Client Initiated Connections in the Session Initiation Protocol (SIP),” June 2006.</span><span>)</span></a>.
</p>
<a name="anchor3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3"></a><h3>3. Introduction</h3>
<p><a class="info" href="#RFC3261">SIP<span> (</span><span class="info">Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.</span><span>)</span></a>[1] entities can communicate using either
unreliable/connectionless (e.g., UDP) or reliable/connection-oriented
(e.g., TCP, <a class="info" href="#RFC2960">SCTP<span> (</span><span class="info">Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, “The Session Initiation Protocol (SIP)-Specific Event Notification,” October 2000.</span><span>)</span></a>[14]) 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.
</p>
<p>In the following example, Entity A listens for SIP requests over
<a class="info" href="#RFC2246">TLS<span> (</span><span class="info">Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.</span><span>)</span></a>[3] on TCP port 5061 (the default port for
SIP over TLS over TCP), but uses an ephemeral port (port 8293) for a
new connection to Entity B. These entities could be SIP User Agents or
SIP Proxy Servers.
</p><pre>
+-----------+ 8293 (UAC) 5061 (UAS) +-----------+
| |--------------------------->| |
| Entity | | Entity |
| A | | B |
| | 5061 (UAS) | |
+-----------+ +-----------+
Figure 1: Uni-directional connection for requests from A to B.
</pre>
<p>The SIP protocol includes mechanisms which insure that responses to
a request reuse the existing connection which is typically still available,
and also includes provisions for reusing existing connections for other
requests sent by the originator of the connection. However, new requests
sent in the opposite direction -- 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.
</p><pre>
+-----------+ 8293 5061 +-----------+
| |.......................>| |
| Entity | | Entity |
| A | 5061 9741 | B |
| |<-----------------------| |
+-----------+ +-----------+
Figure 2: Two connections for requests between A and B.
</pre>
<p>While this is adequate for TCP, and indeed is the only way to
securely do connection reuse over that transport (see
<a class="info" href="#auth-tcp">Section 9.3<span> (</span><span class="info">Security Considerations for the TCP Transport</span><span>)</span></a>), TLS connections can be reused 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 the
connection opened from Entity A to Entity B is shared. When Entity
A wants to send a request to Entity B, it will reuse this connection, and
when Entity B wants to send a request to Entity A, it will reuse
the same connection.
</p>
<a name="anchor4"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4"></a><h3>4. Benefits of TLS Connection Reuse</h3>
<p>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
<a class="info" href="#Book-Rescorla-TLS">[9]<span> (</span><span class="info">Rescorla, E., “SSL and TLS: Designing and Building Secure Systems,” 2001.</span><span>)</span></a>).
</p>
<p>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.
</p><pre>
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
Figure 3: Multiple connections for requests.
</pre>
<p>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
<a class="info" href="#RFC3265">[13]<span> (</span><span class="info">Roach, A., “The Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.</span><span>)</span></a> or a REFER <a class="info" href="#RFC3515">[12]<span> (</span><span class="info">Sparks, R., “The Session Initiation Protocol (SIP) Refer Method,” April 2003.</span><span>)</span></a>), can also
cause excessive delay (especially in networks with long round-trip times).
Thus, it is advantageous to reuse connections whenever possible.
</p>
<p>From the user expectation point of view, it is advantageous if the
re-INVITEs or <a class="info" href="#RFC3311">UPDATE<span> (</span><span class="info">Rosenberg, J., “The Session Initiation Protocol (SIP) UPDATE Method,” September 2002.</span><span>)</span></a>[10] 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 <a class="info" href="#RFC3725">RFC3725<span> (</span><span class="info">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.</span><span>)</span></a>[11] use many reINVITEs).
</p>
<p>The mechanism described in this document can mitigate the delays
associated with subsequent requests.
</p>
<a name="overview"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.5"></a><h3>5. Overview of Operation</h3>
<p>This section is tutorial in nature, and does not specify any normative
behavior.
</p>
<p>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.
</p>
<p>P1 and P2 are proxies responsible for routing SIP requests through
user agents that use them as edge proxies (see Figure 4).
</p><pre>
P1 <===================> P2
p1.example.com p2.example.com
(192.0.2.1) (192.0.2.128)
+---+ +---+
| | 0---0 0---0 | |
|___| /-\ /-\ |___|
/ / +---+ +---+ / /
+----+ +----+
User Agents User Agents
Figure 4: Proxy setup.
</pre>
<a name="rfc.section.5.1"></a><h4><a name="ss-tls-ops">5.1</a> TLS Operations</h4>
<p>The act of reusing a connection is initiated by an user agent
client (UAC) when it adds an "alias" parameter (defined later) to the
Via header. When a user agent server (UAS) receives the request, it
examines the topmost Via header. If the header contained an "alias"
parameter, the UAS establishes a binding such that subsequent requests
going to the UAC will reuse the connection; i.e., requests are sent
over the established connection.
</p>
<p>With reference to Figure 4, in order for P2 to reuse a connection
for requests in the opposite 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 reverse 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.
</p>
<p>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. User agents can consult
the alias table for an existing connection before opening up a new one.
</p>
<p>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:
</p>
<p>Via: SIP/2.0/TLS p1.example.com;branch=z9hG4bKa7c8dze;alias
</p>
<p>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 <a class="info" href="#auth-tls-client">Section 9.1<span> (</span><span class="info">Authenticating TLS Connections: Client View</span><span>)</span></a>).
Upon connection authentication and acceptance, P1 adds P2s to its
alias table. P1's alias table now looks like:
</p><pre>
Destination Destination Destination Destination Alias
IP Address Port Transport Identity Descriptor
...
192.0.2.128 5061 TLS DNS:p2.example.com, 25
sips:example.com
Figure 5: Alias table at the client.
</pre>
<p>Subsequent requests that traverse from P1 to P2 will reuse this
connection; i.e., the requests will be sent over the descriptor 25.
</p>
<p>There are three items of interest in the alias table created at the
client:
</p>
<ol class="text">
<li>The IP address, port and transport are a result of executing
RFC3263 server resolution process on a next hop URI.
</li>
<li>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 <a class="info" href="#auth-tls-client">Section 9.1<span> (</span><span class="info">Authenticating TLS Connections: Client View</span><span>)</span></a>).
</li>
<li>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:
</li>
<blockquote class="text"><dl>
<dt>A</dt>
<dd>P1 determines through RFC3263 server resolution process that the
request should be sent to P2 on port 5061 using TLS, and
</dd>
<dt>B</dt>
<dd>The URI used for RFC3263 server resolution matches one of the
identities stored in the cached certificate (fourth column).
</dd>
</dl></blockquote>
</ol>
<p>When the server, P2, receives the request, it examines the topmost Via
to determine whether P1 supports aliased connections. The Via at P2 now
looks like (the "received" parameter is added by P2):
</p><pre>
Via: SIP/2.0/TLS p1.example.com;branch=z9hG4bKa7c8dze;alias;
received=192.0.2.1
</pre>
<p>The presence of the "alias" parameter indicates that P1 does support
aliasing. P2 now authenticates the connection (see <a class="info" href="#auth-tls-server">Section 9.2<span> (</span><span class="info">Authenticating TLS Connections: Server View</span><span>)</span></a>) 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:
</p><pre>
Destination Destination Destination Destination Alias
IP Address Port Transport Identity Descriptor
...
192.0.2.1 5061 TLS DNS:p1.example.com, 18
sips:example.com
Figure 6: Alias table at the server.
</pre>
<p>There are a few items of interest here:
</p>
<ol class="text">
<li>The IP address field is populated with the source address of
the client.
</li>
<li>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.
</li>
<li>The transport field is populated from the advertised address (topmost
Via header).
</li>
<li>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 <a class="info" href="#auth-tls-server">Section 9.2<span> (</span><span class="info">Authenticating TLS Connections: Server View</span><span>)</span></a>).
</li>
<li>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:
</li>
<blockquote class="text"><dl>
<dt>A</dt>
<dd>P2 determines through RFC3263 server resolution process that the
request should be sent to P1 on port 5061 using TLS, and
</dd>
<dt>B</dt>
<dd>The URI used for RFC3263 server resolution matches one of the
identities stored in the cached certificate (fourth column).
</dd>
</dl></blockquote>
<li>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.
</li>
</ol>
<a name="rfc.section.5.2"></a><h4><a name="ss-tcp-ops">5.2</a> TCP Operations</h4>
<p>Connection reuse on the TCP transport is done differently from the
TLS case. This is to prevent a service hijacking security attack
outlined in <a class="info" href="#auth-tcp">Section 9.3<span> (</span><span class="info">Security Considerations for the TCP Transport</span><span>)</span></a>.
</p>
<p>In TCP, connection reuse is accomplished by each host pro-actively
opening up a TCP connection towards its neighbor. Thus, two TCP
connections will be needed between an adjacent pair of hosts, as
depicted in Figure 2.
</p>
<p>The presence of the "alias" parameter in the topmost Via for a
TCP transport is not required.
</p>
<p>From an operations point of view, the same data structure used
to maintain TLS connections can be used for TCP connections as well.
For TCP connections, the contents of this table will be slightly
different in two ways: first, the "Destination Transport" will be
"TCP", and second, the "Destination Identity" is null, or empty.
</p>
<p>With reference to Figure 4, P1 gets a request from one of its
upstream user agents, and after performing RFC3263 server selection,
arrives at the resolved address of P2. P1 populates the alias table
with the IP address, port number, and transport of P2 as determined
through RFC3263 server selection. The value of 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:
</p>
<p>Via: SIP/2.0/TCP p1.example.com;branch=z9hG4bKa7c8dze
</p>
<p>Assuming that P1 does not already have an existing entry with P2's
resolved address in the alias table, P1 now opens up a new TCP connection
with P2. When P2 accepts the connection, P1 adds P2 to its alias
table. P1's alias table now looks like:
</p><pre>
Destination Destination Destination Destination Alias
IP Address Port Transport Identity Descriptor
...
192.0.2.128 5060 TCP - 32
Figure 7: Alias table at the client for TCP transport.
</pre>
<p>Because this same TCP connection cannot be used to send requests
from P2 to P1, P2 will not update its alias table. Instead, at a
later time, if a request from P2 is destined towards P1, P2 will actively
open up a new TCP connection towards P1, and update its alias table
accordingly. Once this is done, P1 and P2 will reuse the same connections
that they established proactively for subsequent requests.
</p>
<a name="anchor5"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.6"></a><h3>6. Requirements</h3>
<p>The following are the requirements that motivated this specification:
</p>
<p></p>
<ol class="text">
<li>A connection sharing mechanism SHOULD allow SIP entities to reuse existing
connections for requests and responses originated from either peer in the
connection.
</li>
<li>A connection sharing mechanism MUST NOT require clients to send
all traffic from well-know SIP ports.
</li>
<li>A connection sharing mechanism MUST NOT require configuring ephemeral port
numbers in DNS.
</li>
<li>A connection sharing mechanism MUST prevent unauthorized hijacking of
other connections.
</li>
<li>Connection sharing SHOULD persist across SIP transactions and dialogs.
</li>
<li>Connection sharing MUST work across name-based virtual SIP servers.
</li>
<li>There is no requirement to share a complete path for ordinary connection
reuse. Hop-by-hop connection sharing is more appropriate.
</li>
</ol><p>
</p>
<a name="anchor6"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.7"></a><h3>7. Formal Syntax</h3>
<p>The following syntax specification uses the augmented Backus-Naur Form (BNF)
as described in <a class="info" href="#RFC4234">RFC 4234<span> (</span><span class="info">Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” October 2005.</span><span>)</span></a>[5]. This document
extends the via-params to include a new via-alias defined below.
</p><pre>
via-params =/ via-alias
via-alias = "alias"
</pre>
<a name="anchor7"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.8"></a><h3>8. Normative Behavior</h3>
<p>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.
</p>
<p>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.
</p>
<p></p>
<blockquote class="text">
<p>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.
</p>
</blockquote>
<a name="rfc.section.8.1"></a><h4><a name="anchor8">8.1</a> Client Behavior</h4>
<p>For the TCP transport, when the client executes the RFC3263 server
selection mechanism to arrive at an IP address, port, and transport tuple
to send the request to, it updates the alias table with this information.
Subsequent requests that resolve to the same IP address, port, and
transport tuple MUST reuse the same connection. The client must
keep the connection open for as long as the resources on the operating
system allow it to. It MUST only accept responses over this connection
and MUST NOT accept any requests over this connection.
</p>
<p>For TCP transports, the client MUST NOT update the topmost Via that
it inserts with the "alias" parameter.
</p>
<p>The rest of the discussion below applies to only the TLS transport.
</p>
<p>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).
</p>
<p>The implications of placing an "alias" parameter in the topmost Via
header of a request must be understood by the client. Specifically, this
means that 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 MUST
reuse the connection when subsequent requests in the same or different
transactions are destined to the same resolved address.
</p>
<p></p>
<blockquote class="text">
<p>Note that RFC3261 states that a response should arrive over the same
connection that was opened for a request.
</p>
</blockquote>
<p>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.
</p>
<p>For TLS connections, clients MUST authenticate the connection before
forming an alias; <a class="info" href="#auth-tls-client">Section 9.1<span> (</span><span class="info">Authenticating TLS Connections: Client View</span><span>)</span></a> 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.
</p>
<p>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:
</p>
<ol class="text">
<li>The client uses the RFC3263 resolution on a URI and arrives at a
resolved address contained in the alias table, and
</li>
<li>The URI used for RFC3263 server resolution matches one of the
identities stored in the alias table row corresponding to that resolved
address.
</li>
</ol>
<a name="rfc.section.8.2"></a><h4><a name="anchor9">8.2</a> Server Behavior</h4>
<p>A TCP connection accepted at the server is used by the server to only
send responses upstream. It MUST NOT be used to send requests. Furthermore,
if the topmost Via header of a request that arrived over TCP had the
"alias" parameter in it, the server MUST NOT accord any semantics to
this parameter.
</p>
<p>The rest of the discussion below applies to only the TLS transport.
</p>
<p>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.
</p>
<p>Whether or not to honor an aliased connection 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.
</p>
<p></p>
<blockquote class="text">
<p>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.
</p>
</blockquote>
<p>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.
</p>
<p>If the Via sent-by contains a port, it MUST be used as a destination
port. Otherwise the default port is the destination port.
</p>
<p>Servers must authenticate the connection before forming an alias.
<a class="info" href="#auth-tls-server">Section 9.2<span> (</span><span class="info">Authenticating TLS Connections: Server View</span><span>)</span></a> discusses the authentication steps
in more detail.
</p>
<p>The server, if it decides to accept 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
<a class="info" href="#overview">Section 5<span> (</span><span class="info">Overview of Operation</span><span>)</span></a> for the contents of the alias table.)
</p>
<p>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:
</p>
<ol class="text">
<li>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
</li>
<li>The URI used for RFC3263 server resolution matches one of the
identities stored in the alias table row corresponding to that
resolved address.
</li>
</ol>
<a name="auth"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.9"></a><h3>9. Security Considerations</h3>
<p>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.
</p>
<a name="rfc.section.9.1"></a><h4><a name="auth-tls-client">9.1</a> Authenticating TLS Connections: Client View</h4>
<p>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 <a class="info" href="#I-D.domain-certs">[7]<span> (</span><span class="info">Gurbani, V., Jeffrey, A., and S. Lawrence, “Domain Certificates in the Session Initiation Protocol (SIP),” August 2006.</span><span>)</span></a>.
</p>
<a name="rfc.section.9.2"></a><h4><a name="auth-tls-server">9.2</a> Authenticating TLS Connections: Server View</h4>
<p>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 <a class="info" href="#I-D.domain-certs">[7]<span> (</span><span class="info">Gurbani, V., Jeffrey, A., and S. Lawrence, “Domain Certificates in the Session Initiation Protocol (SIP),” August 2006.</span><span>)</span></a>.
</p>
<p>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.
</p>
<a name="rfc.section.9.3"></a><h4><a name="auth-tcp">9.3</a> Security Considerations for the TCP Transport</h4>
<p>The mechanism for reusing TLS connections MUST NOT be used to
reuse TCP connections because there isn't any way to perform the
authentication step. Instead, it is RECOMMENDED that TCP peers that
want to avail of connection reuse do so such that each peer actively
opens up a TCP connection in the direction of the other (as depicted in
Figure 2). This manner of opening connections, while still not secure,
is at least much more apparent and direct than using the connection
reuse mechanism over TCP in an unauthenticated fashion.
</p>
<p>Connection reuse over TCP is inherently insecure. Because the
nature of the aliasing mechanism is such that it redirects requests
destined for one port at a host to another port, service hi-jacking can
result if adequate care is not taken to ensure that the redirected port
is indeed authorized to receive the requests that would normally have
gone to another, authorized port. Consider the following scenario to
understand the service hi-jacking attack that can be mounted when using
connection reuse over TCP.
</p>
<p>A TCP server receives a request with the topmost Via header as follows
(the "received" parameter is added by the server after getting the
request):
</p><pre>
Via: SIP/2.0/TCP uac.example.com;branch=z9hG4bKa7c8dze;
received=192.0.4.33
</pre>
<p>If we were to allow TCP connection reuse in the same manner as TLS
connection reuse, then the server would update its alias table such that
whenever a request is destined to 192.0.4.33, port 5060, it will instead
be sent to the peer at the end of the aliased connection. A security attack
can now be mounted as follows: assume a malware program is running on
a multi-user computer. The malware program knows that a user on the
computer runs a SIP user agent, but the SIP user agent is currently not
active (possibly by scanning ports on the local machine to seek a busy
port 5060). Note that the malware program does not need to wait until the
legitimate user agent was not running, however, doing so increases the
chances that the server will not reject the malware program's request.
Once the malware program decides that a legitimate user agent is not
running, it sends a request to the server with an "alias" parameter.
The server believes it is accepting a request from a legitimate user agent
and sends subsequent requests to the aliased connection. The SIP service
on the computer has now effectively been hi-jacked for the default port.
The malware program does not need administrative privileges to execute,
and in fact, can masquerade as any user (legitimate or not) of the computer.
</p>
<p>Later on, when the legitimate user agent is started, it may also send a
request with an "alias" parameter to the server, which may detect
that it now has two aliased connections. Making matters much worse,
it cannot determine which of the two is the legitimate one and may
well reject the request from the legitimate user.
</p>
<p>In another form of this attack, the legitimate user agent may not
support connection aliasing, but the malware program may use the
mechanism to usurp the SIP service on the computer.
</p>
<p>In yet another form of an attack, the malware program uses the aliasing
mechanism to shortcut registering with a proxy to receive requests. In
this case, it sends a request to the edge proxy (who may also substitute
as the inbound proxy with access to a location service for that domain).
In the request is a bogus request URI that will cause the edge proxy
to fail the request, however, the edge proxy keeps the connection open
and any subsequent requests destined to that host on the default port
are instead sent to the malware program. Registration is thus not needed
in order to receive incoming requests.
</p>
<p>HTTP Digest is useful to mitigate only a subset of these attacks over TCP.
For instance, HTTP Digest helps in authenticating a user agent to a
proxy server before the alias table is updated. However, HTTP Digest is
of no help when one proxy desires to enter an aliasing agreement with another
downstream proxy.
</p>
<a name="virt-server"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.10"></a><h3>10. Support for Virtual Servers</h3>
<p>Virtual servers present special considerations for connection
reuse. Under the name-based virtual server scheme, one SIP proxy
may host many virtual domains. If adequate defenses are not put in
place, a connection opened to a downstream server on behalf of one
domain can be usurped by a malicious user in another domain. The
Destination Identity column in the alias table has been added to
aid in such defenses. If an implementation does not support virtual
SIP servers, it MAY omit caching the identities in the alias table;
however, if an implementation supports virtual SIP servers, then it
MUST cache the identities in the alias table.
</p>
<a name="rfc.section.10.1"></a><h4><a name="ss-virt-server-TLS">10.1</a> Virtual Servers and TLS Connections</h4>
<p>To understand the specific problem associated with hijacking a
TLS connection when virtual servers are used, consider a proxy P1
that hosts two domains: atlanta.example.com and chicago.example.org.
Also assume that the physical IP address of P1 is 192.168.0.1.
Incoming requests to all the domains that P1 hosts arrive on
port 5061.
</p>
<p>A user, bob@atlanta.example.com, sends an instant message to a
user Alice in a domain not hosted by P1. Alice's proxy establishes an
alias to P1, thereby resulting in the following alias table (note:
to illustrate the connection hijacking problem associated with
virtual servers, the alias table below does not contain the
Destination Identity column).
</p><pre>
Destination Destination Destination Alias
IP Address Port Transport Descriptor
...
192.168.0.1 5061 TLS 25
Figure 8: Alias table at Alice's Proxy.
</pre>
<p>At some later time, a user hosted by another virtual domain in P1,
bob@chicago.example.org, sends an instant message to Alice.
Alice's proxy will get the network identifiers from the topmost Via,
and note that they are already in the alias table. Thinking that
the newly arrived request is intended to replace the old (possibly
stale) alias, it may update its alias table with the new descriptor.
</p>
<p>Some time after that, Alice wants to send an instant message to
sips:bob@atlanta.example.com. When RFC3263 resolution is done on
sips:atlanta.example.com, the resolved address will match an entry
in the alias table. But that entry is now aliased to a connection
with bob@chicago.example.org. The end result of all this is that
an instant message intended for bob@atlanta.example.com ends up in
the inbox of bob@chicago.example.org.
</p>
<p>It is to alleviate this very problem that the identities from
the X.509 certificates are stored in the alias table and used to
determine whether or not to reuse a connection. Saving the identities
in the alias table mitigates this problem because Alice's proxy will
actually form two aliased connections to P1: one row in the table
will contain the resolved address of P1 but with an identity corresponding
to atlanta.example.com and a second row will contain the same resolved
address but with an identity corresponding to chicago.example.org. Now,
when Alice's proxy wants to send a request in the backwards direction,
it will match the URI used to do RFC3263 resolution to the appropriate
identity before reusing the connection.
</p>
<a name="anchor10"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.11"></a><h3>11. Connection Reuse and SRV Interaction</h3>
<p>Connection reuse has an interaction with the DNS SRV load balancing
mechanism. To understand the interaction, consider the following figure:
</p><pre>
/+---- S1
+-------+/
| Proxy |------- S2
+-------+\
\+---- S3
Figure 9: Load balancing.
</pre>
<p>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.
</p>
<a name="anchor11"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.12"></a><h3>12. IANA Considerations</h3>
<p>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 <a class="info" href="#RFC3968">[6]<span> (</span><span class="info">Camarillo, G., “The Internet Assigned Numbers Authority (IANA) Header Field Paramater Registry for the Session Initiation Protocol (SIP),” December 2004.</span><span>)</span></a>.
The required information is:
</p><pre>
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.]
</pre>
<a name="anchor12"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.13"></a><h3>13. Acknowledgments</h3>
<p>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.
</p>
<a name="rfc.references"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.14"></a><h3>14. References</h3>
<a name="rfc.references1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<h3>14.1 Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="RFC3261">[1]</a></td>
<td class="author-text">Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “<a href="http://www.ietf.org/rfc/rfc3261.txt">SIP: Session Initiation Protocol</a>,” RFC 3261, June 2002.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2119">[2]</a></td>
<td class="author-text">Bradner, S., “<a href="http://www.ietf.org/rfc/rfc2119.txt">Key words for use in RFCs to Indicate Requirement Levels</a>,” RFC 2119, March 1997.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2246">[3]</a></td>
<td class="author-text">Dierks, T. and C. Allen, “<a href="http://www.ietf.org/rfc/rfc2246.txt">The TLS Protocol Version 1.0</a>,” RFC 2246, January 1999.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3263">[4]</a></td>
<td class="author-text">Rosenberg, J. and H. Schulzrinne, “<a href="http://www.ietf.org/rfc/rfc3263.txt">Session Initiation Protocol (SIP): Locating SIP Servers</a>,” RFC 3263, June 2002.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC4234">[5]</a></td>
<td class="author-text">Crocker, D. and P. Overell, “<a href="http://www.ietf.org/rfc/rfc4234.txt">Augmented BNF for Syntax Specifications: ABNF</a>,” RFC 4234, October 2005.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3968">[6]</a></td>
<td class="author-text">Camarillo, G., “<a href="http://www.ietf.org/rfc/rfc3968.txt">The Internet Assigned Numbers Authority (IANA) Header
Field Paramater Registry for the Session Initiation Protocol (SIP)</a>,” BCP 98, RFC 3968, December 2004.</td></tr>
<tr><td class="author-text" valign="top"><a name="I-D.domain-certs">[7]</a></td>
<td class="author-text">Gurbani, V., Jeffrey, A., and S. Lawrence, “<a href="http://www.ietf.org/internet-drafts/draft-gurbanipsip-domain-certs-03.txt">Domain Certificates in the Session Initiation Protocol (SIP)</a>,” draft-gurbani-sip-domain-certs-03 (work in progress), August 2006.</td></tr>
</table>
<a name="rfc.references2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<h3>14.2 Informational References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="I-D.ietf-sip-outbound">[8]</a></td>
<td class="author-text">Jennings, C. and R. Mahy, “<a href="http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-04.txt">Managing Client Initiated Connections in the Session Initiation
Protocol (SIP)</a>,” draft-ietf-sip-outbound-04.txt (work in progress), June 2006.</td></tr>
<tr><td class="author-text" valign="top"><a name="Book-Rescorla-TLS">[9]</a></td>
<td class="author-text">Rescorla, E., “SSL and TLS: Designing and Building Secure Systems,” Addison-Wesley Publishing , 2001.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3311">[10]</a></td>
<td class="author-text">Rosenberg, J., “<a href="http://www.ietf.org/rfc/rfc3311.txt">The Session Initiation Protocol (SIP) UPDATE Method</a>,” RFC 3311, September 2002.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3725">[11]</a></td>
<td class="author-text">Rosenberg, J., Peterson, J., Schulzrinne, H., and H. Camarillo, “<a href="http://www.ietf.org/rfc/rfc3725.txt">Best Current Practices for Third Party Call Control (3pcc) in the
Session Initiation Protocol (SIP)</a>,” RFC 3725, April 2004.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3515">[12]</a></td>
<td class="author-text">Sparks, R., “<a href="http://www.ietf.org/rfc/rfc3515.txt">The Session Initiation Protocol (SIP) Refer Method</a>,” RFC 3515, April 2003.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3265">[13]</a></td>
<td class="author-text">Roach, A., “<a href="http://www.ietf.org/rfc/rfc3265.txt">The Session Initiation Protocol (SIP)-Specific Event Notification</a>,” RFC 3265, June 2002.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2960">[14]</a></td>
<td class="author-text">Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, “<a href="http://www.ietf.org/rfc/rfc2960.txt">The Session Initiation Protocol (SIP)-Specific Event Notification</a>,” RFC 2960, October 2000.</td></tr>
</table>
<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<h3>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text"> </td>
<td class="author-text">Rohan Mahy</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Plantronics</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:rohan@ekabal.com">rohan@ekabal.com</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Vijay K. Gurbani (editor)</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Lucent Technologies, Inc./Bell Laboratories</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:vkg at acm dot org">vkg at acm dot org</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Brett Tate</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">BroadSoft</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:brett@broadsoft.com">brett@broadsoft.com</a></td></tr>
</table>
<a name="rfc.copyright"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<h3>Intellectual Property Statement</h3>
<p class='copyright'>
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.</p>
<p class='copyright'>
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 <a href='http://www.ietf.org/ipr'>http://www.ietf.org/ipr</a>.</p>
<p class='copyright'>
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 <a href='mailto:ietf-ipr@ietf.org'>ietf-ipr@ietf.org</a>.</p>
<h3>Disclaimer of Validity</h3>
<p class='copyright'>
This document and the information contained herein are provided
on an “AS IS” basis and THE CONTRIBUTOR,
THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY),
THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM
ALL WARRANTIES,
EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</p>
<h3>Copyright Statement</h3>
<p class='copyright'>
Copyright © The Internet Society (2006).
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.</p>
<h3>Acknowledgment</h3>
<p class='copyright'>
Funding for the RFC Editor function is currently provided by the
Internet Society.</p>
</body></html>
| PAFTECH AB 2003-2026 | 2026-04-23 10:57:57 |