[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-mahy-sip-connect-reuse) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 RFC 5923

SIP WG                                                           R. Mahy
Internet-Draft                                               Plantronics
Updates: 3261 (if approved)                              V. Gurbani, Ed.
Expires: February 22, 2007                Lucent Technologies, Inc./Bell
                                                            Laboratories
                                                                 B. Tate
                                                               BroadSoft
                                                         August 21, 2006


       Connection Reuse in the Session Initiation Protocol (SIP)
                    draft-ietf-sip-connect-reuse-06

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on February 22, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   When SIP entities use a connection oriented protocol to send a
   request, they typically originate their connections from an ephemeral
   port.  The SIP protocol includes mechanisms which insure that
   responses to a request, and new requests sent in the original



Mahy, et al.            Expires February 22, 2007               [Page 1]

Internet-Draft            SIP Connection Reuse               August 2006


   direction reuse an existing connection.  However, new requests sent
   in the opposite direction are unlikely to reuse the existing
   connection.  This frequently causes a pair of SIP entities to use one
   connection for requests sent in each direction, and can result in
   potential scaling and performance problems.  This document proposes
   requirements and a mechanism which address this deficiency in
   environments where the connection could be opened in either
   direction.

Table of Contents

   1.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Applicability Statement  . . . . . . . . . . . . . . . . . .   3
   3.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.   Benefits of Connection Reuse . . . . . . . . . . . . . . . .   4
   5.   Overview of Operation  . . . . . . . . . . . . . . . . . . .   5
   6.   Requirements . . . . . . . . . . . . . . . . . . . . . . . .   9
   7.   Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . .   9
   8.   Normative Behavior . . . . . . . . . . . . . . . . . . . . .   9
     8.1  Client Behavior  . . . . . . . . . . . . . . . . . . . . .  10
     8.2  Server Behavior  . . . . . . . . . . . . . . . . . . . . .  11
   9.   Security Considerations  . . . . . . . . . . . . . . . . . .  13
     9.1  Authenticating TLS Connections: Client View  . . . . . . .  13
     9.2  Authenticating TLS Connections: Server View  . . . . . . .  13
     9.3  Security Considerations for the TCP Transport  . . . . . .  13
   10.  Support for Virtual Servers  . . . . . . . . . . . . . . . .  15
     10.1   Virtual Servers and TLS Connections  . . . . . . . . . .  15
     10.2   Virtual Servers and TCP Connections  . . . . . . . . . .  16
   11.  Connection Reuse and SRV Interaction . . . . . . . . . . . .  17
   12.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  18
   13.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  18
   14.  References . . . . . . . . . . . . . . . . . . . . . . . . .  18
     14.1   Normative References . . . . . . . . . . . . . . . . . .  18
     14.2   Informational References . . . . . . . . . . . . . . . .  19
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  20
        Intellectual Property and Copyright Statements . . . . . . .  21















Mahy, et al.            Expires February 22, 2007               [Page 2]

Internet-Draft            SIP Connection Reuse               August 2006


1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [2].

   Additional terminology used in this document:

   Advertised address The address that occurs in the Via sent-by
      production rule, including the port number and transport.
   Alias A transport layer connection associated with a resolved
      address.
   Resolved address The network identifiers (IP address, port,
      transport) associated with a user agent as a result of executing
      RFC3263 [4] on a Uniform Resource Identifier (URI).

2.  Applicability Statement

   The applicability of the mechanism described in this document is for
   two adjacent SIP entities to reuse connections when they are agnostic
   about the direction of the connection, i.e., either end can initiate
   the connection.  SIP entities that can only open a connection in a
   specific direction -- perhaps because of Network Address Translation
   (NAT) and firewall reasons -- reuse their connections using the
   mechanism described in [8].

   The connect reuse mechanism described in this document is defined
   only for Transport Layer Security (TLS) transports.  Furthermore, it
   is assumed that both the peers using TLS possess X.509 certificates.
   Implementations MUST NOT use this mechanism for the TCP transport due
   to the possible attacks that can be launched with connection reuse
   over TCP.  Such attacks and alternative methods for connection reuse
   over TCP are described in Section 9.3.

3.  Introduction

   SIP [1] entities can communicate using either unreliable/
   connectionless (e.g., UDP) or reliable/connection-oriented (e.g.,
   TCP, SCTP [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.

   In the following example, Entity A listens for SIP requests over TLS
   [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.





Mahy, et al.            Expires February 22, 2007               [Page 3]

Internet-Draft            SIP Connection Reuse               August 2006


          +-----------+ 8293 (UAC)      5061 (UAS) +-----------+
          |           |--------------------------->|           |
          |  Entity   |                            |  Entity   |
          |     A     |                            |     B     |
          |           | 5061 (UAS)                 |           |
          +-----------+                            +-----------+

   Figure 1: Uni-directional connection for requests from A to B.


   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.

          +-----------+ 8293              5061 +-----------+
          |           |.......................>|           |
          |  Entity   |                        |  Entity   |
          |     A     | 5061              9741 |     B     |
          |           |<-----------------------|           |
          +-----------+                        +-----------+

   Figure 2: Two connections for requests between A and B.


   While this is adequate for TCP, and indeed is the only way to
   securely do connection reuse over that transport (see Section 9.3),
   TLS connections can be reused since each end can be authenticated
   when the connection is initially set up.

4.  Benefits of Connection Reuse

   Opening an extra connection where an existing one is sufficient can
   result in potential scaling and performance problems.  Each new
   connection using TLS requires a TCP 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 [9]).

   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



Mahy, et al.            Expires February 22, 2007               [Page 4]

Internet-Draft            SIP Connection Reuse               August 2006


   establish a new TLS connection just to send a BYE request.


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

   Figure 3: Multiple connections for requests.

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

   From the user expectation point of view, it is advantageous if the
   re-INVITEs or UPDATE [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 RFC3725 [11] use many reINVITEs).

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

5.  Overview of Operation

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

   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



Mahy, et al.            Expires February 22, 2007               [Page 5]

Internet-Draft            SIP Connection Reuse               August 2006


   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.

   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.

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

                   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.

   This document is concerned with specifying an extension to SIP for
   connection reuse at the receiving end; i.e., reusing the connection
   when P2 wants to send a request to P1.  However, it should be
   sufficiently clear that the sending end (P1) may also reuse a
   connection previously established downstream (to P2, for instance).

   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.

   To aid in connection reuse, a new data structure, the connection
   alias table (or simply, alias table) is defined in this document and



Mahy, et al.            Expires February 22, 2007               [Page 6]

Internet-Draft            SIP Connection Reuse               August 2006


   it is used to store the resolved addresses.  User agents can consult
   the alias table for an existing connection before opening up a new
   one.

   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:

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

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

   Destination  Destination  Destination  Destination      Alias
   IP Address   Port         Transport    Identity         Descriptor
   ...
   192.0.2.128  5061         TLS       DNS:p2.example.com,  25
                                       sips:example.com
   Figure 5: Alias table at the client.

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

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





Mahy, et al.            Expires February 22, 2007               [Page 7]

Internet-Draft            SIP Connection Reuse               August 2006


       A.  P1 determines through RFC3263 server resolution process that
           the request should be sent to P2 on port 5061 using TLS, and
       B.  The URI used for RFC3263 server resolution matches one of the
           identities stored in the cached certificate (fourth column).

   When the server, P2, receives the request, it may add a "received"
   parameter to the topmost Via and examines the topmost Via to
   determine whether P1 supports aliased connections.  The Via at P2 now
   looks like:

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

   The presence of the "alias" parameter indicates that P1 does support
   aliasing.  P2 now authenticates the connection (see Section 9.2) and
   if the authentication was successful, P2 creates an alias to P1 using
   the advertised address in the topmost Via. P2's alias table looks
   like:

   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.

   There are a few items of interest here:
   1.  The IP address field is populated with the source address of the
       client.
   2.  The port field is populated from the advertised address (topmost
       Via header), if a port is present in it, or 5061 if it is not.
   3.  The transport field is populated from the advertised address
       (topmost Via header).
   4.  The entries in the fourth column consist of the identities of the
       client as asserted in the X.509 certificate presented by the
       client.  These identities are cached by the server after the
       client has been duly authenticated (see Section 9.2).
   5.  The entry in the last column is the socket descriptor over which
       the connection was passively accepted.  At some later time, when
       P2 gets a request from one of the user agents in its domain, it
       will reuse the aliased connection accessible through socket
       descriptor 18 if and only if all of the following conditions
       hold:
       A.  P2 determines through RFC3263 server resolution process that
           the request should be sent to P1 on port 5061 using TLS, and
       B.  The URI used for RFC3263 server resolution matches one of the
           identities stored in the cached certificate (fourth column).




Mahy, et al.            Expires February 22, 2007               [Page 8]

Internet-Draft            SIP Connection Reuse               August 2006


   6.  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.

6.  Requirements

   The following are the requirements that motivated this specification:

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

7.  Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in RFC 4234 [5].  This document extends the
   via-params to include a new via-alias defined below.

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


8.  Normative Behavior

   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.




Mahy, et al.            Expires February 22, 2007               [Page 9]

Internet-Draft            SIP Connection Reuse               August 2006


   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.

      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.

   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.

   Because an alias connection might be reclaimed during a transaction,
   clients SHOULD NOT enforce the RFC 3261 requirement of sending CANCEL
   and ACK (for non 2xx responses) to the same port.  If the alias
   connection no longer exists, 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.

8.1  Client Behavior

   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).

   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 -- as opposed to a
   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.

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




Mahy, et al.            Expires February 22, 2007              [Page 10]

Internet-Draft            SIP Connection Reuse               August 2006


   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.

   Clients must be prepared for the case that the connection no longer
   exists 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.

   For TLS connections, clients MUST authenticate the connection before
   forming an alias; Section 9.1 discusses the authentication steps in
   more detail.  Once the server has been authenticated, the client MUST
   cache, in the alias table, the identity (or identities) of the server
   as 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.

   TCP connections, obviously, cannot be authenticated in a similar
   manner as TLS connections; nor can an identity be derived by
   inspecting fields of a certificate.  For TCP connections, clients
   MUST use as the destination identity the URI used as input to the
   RFC3263 server resolution process.

   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:
   1.  The client uses the RFC3263 resolution on a URI and arrives at a
       resolved address contained in the alias table, and
   2.  The URI used for RFC3263 server resolution matches one of the
       identities stored in the alias table row corresponding to that
       resolved address.

8.2  Server Behavior

   When a server receives a request 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



Mahy, et al.            Expires February 22, 2007              [Page 11]

Internet-Draft            SIP Connection Reuse               August 2006


   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.

   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.

      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.

   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.

   If the Via sent-by contains a port, it MUST be used as a destination
   port.  Otherwise the default port is the destination port.

   Servers must authenticate the connection before forming an alias.
   Section 9.2 discusses the authentication steps in more detail.

   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 Section 5 for the contents of the alias table.)

   Once the alias table has been updated, and the server wants to send a
   request in the direction of the client, it should reuse the
   connection only if all of the following conditions hold:
   1.  The server, which acts as a client for this transaction, uses the
       RFC3263 resolution process on a URI and arrives at a resolved
       address contained in the alias table, and





Mahy, et al.            Expires February 22, 2007              [Page 12]

Internet-Draft            SIP Connection Reuse               August 2006


   2.  The URI used for RFC3263 server resolution matches one of the
       identities stored in the alias table row corresponding to that
       resolved address.

9.  Security Considerations

   This document presents requirements and a mechanism for reusing
   existing connections easily.  Unauthenticated connection reuse would
   present many opportunities for rampant abuse and hijacking.
   Authenticating connection aliases is essential to prevent connection
   hijacking.  For example, a program run by a malicious user of a
   multiuser system could attempt to hijack SIP requests destined for
   the well-known SIP port from a large relay proxy.

9.1  Authenticating TLS Connections: Client View

   When a TLS client establishes a connection with a server, it is
   presented with the server's X.509 certificate.  Authentication
   proceeds as described in Section 5 of [7].

9.2  Authenticating TLS Connections: Server View

   A TLS server conformant to this specification MUST ask for a client
   certificate; if the client possesses a certificate, it will be
   presented to the server for mutual authentication, and authentication
   proceeds as described in Section 6 of [7].

   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.

9.3  Security Considerations for the TCP Transport

   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.

   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



Mahy, et al.            Expires February 22, 2007              [Page 13]

Internet-Draft            SIP Connection Reuse               August 2006


   understand the service hi-jacking attack that can be mounted when
   using connection reuse over TCP.

   A TCP server receives a request with the "alias" parameter as follows
   (the "received" parameter is added by the server after getting the
   request):

   Via: SIP/2.0/TCP uac.example.com;branch=z9hG4bKa7c8dze;alias;
      received=192.0.4.33

   From the server's perspective, its alias table is updated 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.
   The 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 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.

   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.

   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.

   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



Mahy, et al.            Expires February 22, 2007              [Page 14]

Internet-Draft            SIP Connection Reuse               August 2006


   program.  Registration is thus not needed in order to receive
   incoming requests.

   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.

10.  Support for Virtual Servers

   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.

10.1  Virtual Servers and TLS Connections

   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.

   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).

   Destination  Destination  Destination  Alias
   IP Address   Port         Transport    Descriptor
   ...
   192.168.0.1  5061         TLS          25

   Figure 7: Alias table at Alice's Proxy.

   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



Mahy, et al.            Expires February 22, 2007              [Page 15]

Internet-Draft            SIP Connection Reuse               August 2006


   arrived request is intended to replace the old (possibly stale)
   alias, it may update its alias table with the new descriptor.

   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.

   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.

10.2  Virtual Servers and TCP Connections

   The same problem described in Section 10.1 occurs for the TCP
   transport as well, however, the mechanics associated are somewhat
   different from the TLS case since connection reuse across TCP
   connections follows the model depicted in Figure 2 (i.e., one
   connection in each direction).  To illustrate the problem
   nonetheless, consider the same proxy and virtual domains of described
   in Section 10.1.

   Alice is interested in sending instant messages to two of her
   colleagues, sip:bob@atlanta.example.com and
   sip:bob@chicago.example.org.  Unbeknownst to her, atlanta.example.com
   and chicago.example.org resolve to the same network identifiers when
   RFC3263 resolution is done on these URIs (they are hosted on P1, a
   proxy that supports multiple virtual domains at one physical address:
   192.168.0.1).

   Alice sends an instant message to her colleague,
   sip:bob@atlanta.example.com.  This act causes her proxy to open up a
   TCP connection to P1 and update its alias table as follows:






Mahy, et al.            Expires February 22, 2007              [Page 16]

Internet-Draft            SIP Connection Reuse               August 2006


   Destination  Destination  Destination  Alias
   IP Address   Port         Transport    Descriptor
   ...
   192.168.0.1  5060         TCP          25

   Figure 8: Alias table at Alice's Proxy.

   At some later time, Alice sends an instant message to her colleague,
   sip:bob@chicago.example.org.  RFC3263 resolution on sip:
   chicago.example.org will result in a set of network identifiers that
   are already present in the alias table of Alice's proxy.  Thus,
   Alice's proxy will not open up a new TCP connection, and instead, use
   the same connection to erroneously deliver the message to the wrong
   recipient.

   Unlike the case of TLS connections, TCP connections do not have
   certificates that can be used to further choose the right aliased
   connection.  Instead of certificates, domain names must be used for
   TCP as follows:

   When Alice's proxy sends the request to a URI, a RFC3263 resolution
   is done on the URI to derive a resolved address.  In addition to
   saving the network identifiers in the alias table, the proxy must
   also save the URI in the Destination Identity column.  That is, if a
   request was sent to sip:bob@atlanta.example.com, then the alias table
   will be populated as follows:

   Destination  Destination  Destination  Destination    Alias
   IP Address   Port         Transport    Identity       Descriptor
   ...
   192.168.10.2  5060         TCP      atlanta.example.com  32

   Figure 9: Alias table at Alice's Proxy with a TCP Destination
   Identity column.

   Subsequent requests sent over the aliased connection must ensure that
   the URI in the Destination Identity column matches the URI where the
   request is being sent.

11.  Connection Reuse and SRV Interaction

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







Mahy, et al.            Expires February 22, 2007              [Page 17]

Internet-Draft            SIP Connection Reuse               August 2006


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

   Figure 8: Load balancing.

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

12.  IANA Considerations

   This specification defines a new Via header field parameter called
   "alias" in the "Header Field Parameters and Parameter Values" sub-
   registry as per the registry created by [6].  The required
   information is:

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

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


13.  Acknowledgments

   Thanks to Jon Peterson for helpful answers about certificate behavior
   with SIP, Jonathan Rosenberg for his initial support of this concept,
   and Cullen Jennings for providing a sounding board for this idea.
   Other members of the SIP WG that contributed to this document include
   Jeroen van Bemmel, Keith Drage, Matthew Gardiner, Rajnish Jain, and
   Rocky Wang.

14.  References

14.1  Normative References

   [1]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement



Mahy, et al.            Expires February 22, 2007              [Page 18]

Internet-Draft            SIP Connection Reuse               August 2006


        Levels", RFC 2119, March 1997.

   [3]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
        RFC 2246, January 1999.

   [4]  Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
        (SIP): Locating SIP Servers", RFC 3263, June 2002.

   [5]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 4234, October 2005.

   [6]  Camarillo, G., "The Internet Assigned Numbers Authority (IANA)
        Header  Field Paramater Registry for the Session Initiation
        Protocol (SIP)", BCP 98, RFC 3968, December 2004.

   [7]  Gurbani, V., Jeffrey, A., and S. Lawrence, "Domain Certificates
        in the Session Initiation Protocol (SIP)",
        draft-gurbani-sip-domain-certs-03 (work in progress),
        August 2006.

14.2  Informational References

   [8]   Jennings, C. and R. Mahy, "Managing Client Initiated
         Connections in the Session Initiation  Protocol (SIP)",
         draft-ietf-sip-outbound-04.txt (work in progress), June 2006.

   [9]   Rescorla, E., "SSL and TLS: Designing and Building Secure
         Systems", Addison-Wesley Publishing , 2001.

   [10]  Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
         Method", RFC 3311, September 2002.

   [11]  Rosenberg, J., Peterson, J., Schulzrinne, H., and H. Camarillo,
         "Best Current Practices for Third Party Call Control (3pcc) in
         the Session Initiation Protocol (SIP)", RFC 3725, April 2004.

   [12]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
         Method", RFC 3515, April 2003.

   [13]  Roach, A., "The Session Initiation Protocol (SIP)-Specific
         Event Notification", RFC 3265, June 2002.

   [14]  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", RFC 2960, October 2000.





Mahy, et al.            Expires February 22, 2007              [Page 19]

Internet-Draft            SIP Connection Reuse               August 2006


Authors' Addresses

   Rohan Mahy
   Plantronics

   Email: rohan@ekabal.com


   Vijay K. Gurbani (editor)
   Lucent Technologies, Inc./Bell Laboratories

   Email: vkg at acm dot org


   Brett Tate
   BroadSoft

   Email: brett@broadsoft.com

































Mahy, et al.            Expires February 22, 2007              [Page 20]

Internet-Draft            SIP Connection Reuse               August 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) 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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Mahy, et al.            Expires February 22, 2007              [Page 21]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/