[Docs] [txt|pdf|xml|html] [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.
Intended status: Standards Track       Bell Laboratories, Alcatel-Lucent
Expires: November 14, 2008                                       B. Tate
                                                               BroadSoft
                                                            May 13, 2008


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

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 November 14, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document enables a pair of communicating proxies to reuse a
   congestion-controlled connection between themselves for sending
   requests in the forward and backwards direction.  Because the
   connection is essentially aliased for requests going in the backwards
   direction, reuse should be predicated upon both the communicating



Mahy, et al.            Expires November 14, 2008               [Page 1]

Internet-Draft            SIP Connection Reuse                  May 2008


   endpoints authenticating themselves using X.509 certificates through
   TLS.  For this reason, we only consider connection reuse for TLS over
   TCP and TLS over SCTP.  A single connection should not be reused for
   the TCP or SCTP transport between two peers, and this document
   provides insight into why this is the case.  As a remedy, it suggests
   using two TCP connections (or two SCTP associations), each opened
   pro-actively towards the recipient by the sender.  Finally, this
   document also provides guidelines on connection reuse and virtual SIP
   servers and the interaction of connection reuse and DNS SRV lookups
   in SIP.


Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  3
   3.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Benefits of TLS Connection Reuse . . . . . . . . . . . . . . .  5
   5.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  6
   6.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  Normative Behavior . . . . . . . . . . . . . . . . . . . . . . 10
     8.1.  Client Behavior  . . . . . . . . . . . . . . . . . . . . . 11
     8.2.  Server Behavior  . . . . . . . . . . . . . . . . . . . . . 12
   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 TCP and SCTP Transports  . . . 14
   10. Connection reuse and Virtual servers . . . . . . . . . . . . . 15
   11. Connection Reuse and SRV Interaction . . . . . . . . . . . . . 16
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   13. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     14.2. Informational References . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 19














Mahy, et al.            Expires November 14, 2008               [Page 2]

Internet-Draft            SIP Connection Reuse                  May 2008


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:  Re-using an existing connection for sending requests in the
      backwards direction; i.e., A opens a connection to B to send a
      request, and B uses that connection to send requests in the
      backwards direction to A.
   Connection reuse:  See "Alias".
   Persistent connection:  The process of sending multiple, possibly
      unrelated requests on the same connection, and receiving responses
      on that connection as well.  More succinctly, A opens a connection
      to B to send a request, and later reuses the same connection to
      send other requests, possibly unrelated to the dialog established
      by the first request.  Responses will arrive over the same
      connection.  Persistent connection behavior is is specified in
      Section 18 of RFC3261 [1].  Persistent connections do not imply
      connection reuse.
   Resolved address:  The network identifiers (IP address, port,
      transport) associated with a user agent as a result of executing
      RFC3263 [4] on a Uniform Resource Identifier (URI).
   Shared connection:  See "Persistent connection."


2.  Applicability Statement

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

   This memo concerns connection reuse, not persistent connections (see
   definitions of these in Section 1).  Behavior for persistent
   connections is specified in Section 18 of RFC3261 [1] and is not
   altered by this memo.

   This memo RECOMMENDS that only those connections be reused where the
   identity of the sender can be verified by the receiver.  Thus, TLS
   connections (over any connection-oriented transport) formed by



Mahy, et al.            Expires November 14, 2008               [Page 3]

Internet-Draft            SIP Connection Reuse                  May 2008


   exchanging X.509 certificates can be reused because they
   authoritatively establish identities of the communicating parties
   (see Section 5).  For reasons discussed in Section 9.3, connection
   reuse over other connection-oriented transport (TCP, SCTP [14]) is
   NOT RECOMMENDED.


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, 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 B. These
   entities could be SIP User Agents or SIP Proxy Servers.

          +-----------+ 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 the notion of a persistent connection,
   which is a mechanisms to insure that responses to a request reuse the
   existing connection that is typically still available, as well as
   reusing the existing connections for other requests sent by the
   originator of the connection.  However, new requests sent in the
   backwards direction -- in the example above, requests from B destined
   to A -- are unlikely to reuse the existing connection.  This
   frequently causes a pair of SIP entities to use one connection for
   requests sent in each direction, as shown below.

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





Mahy, et al.            Expires November 14, 2008               [Page 4]

Internet-Draft            SIP Connection Reuse                  May 2008


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

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


4.  Benefits of TLS Connection Reuse

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



Mahy, et al.            Expires November 14, 2008               [Page 5]

Internet-Draft            SIP Connection Reuse                  May 2008


   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.

   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 to user
   agents that use them as edge proxies (see Figure 4).

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

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


                           Figure 4: Proxy setup




Mahy, et al.            Expires November 14, 2008               [Page 6]

Internet-Draft            SIP Connection Reuse                  May 2008


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

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

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

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

   P1 gets a request from one of its upstream user agents, and after
   performing RFC3263 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



Mahy, et al.            Expires November 14, 2008               [Page 7]

Internet-Draft            SIP Connection Reuse                  May 2008


   authentication and acceptance, P1 adds P2 to its alias table.  P1's
   alias table now looks like:

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


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

   The following columns in the alias table created at the client
   warrant an explanation:
   1.  The IP address, port and transport are a result of executing
       RFC3263 server resolution process on a next hop URI.
   2.  The entries in the fourth column consists of the identities of
       the server as asserted in the X.509 certificate presented by the
       server.  These identities are cached by the client after the
       server has been duly authenticated (see Section 9.1).
   3.  The entry in the last column is the socket descriptor over which
       P1, acting as a client, actively opened a TLS connection.  At
       some later time, when P1 gets a request from one of the user
       agents in its domain, it will reuse the aliased connection
       accessible through socket descriptor 25 if and only if all of the
       following conditions hold:
       A.  P1 determines through RFC3263 server resolution process that
           the {transport, IP-address, port} tuple of P2 to be {TLS,
           192.0.2.128, 5061}, and
       B.  The URI used for RFC3263 server resolution matches one of the
           identities stored in the cached certificate (fourth column).

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

   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 supports
   aliasing on this connection.  P2 now authenticates the connection
   (see Section 9.2) and if the authentication was successful, P2
   creates an alias to P1 using the advertised address in the topmost
   Via. P2's alias table looks like the following:





Mahy, et al.            Expires November 14, 2008               [Page 8]

Internet-Draft            SIP Connection Reuse                  May 2008


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

   There are a few items of interest here:
   1.  The IP address field is populated with the source address of the
       client.
   2.  The port field is populated from the advertised address (topmost
       Via header), 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 {transport, IP-address, port} tuple of P1 to be {TLS,
           192.0.2.1, 5061}, and
       B.  The URI used for RFC3263 server resolution matches one of the
           identities stored in the cached certificate (fourth column).
   6.  The network address inserted in the "Destination IP Address"
       column 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.




Mahy, et al.            Expires November 14, 2008               [Page 9]

Internet-Draft            SIP Connection Reuse                  May 2008


   4.  A connection sharing mechanism MUST prevent unauthorized
       hijacking of other connections.
   5.  Connection sharing SHOULD persist across SIP transactions and
       dialogs.
   6.  Connection sharing MUST work across name-based virtual SIP
       servers.
   7.  There is no requirement to share a complete path for ordinary
       connection reuse.  Hop-by-hop connection sharing is more
       appropriate.


7.  Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in RFC 5234 [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.

   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.

      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.






Mahy, et al.            Expires November 14, 2008              [Page 10]

Internet-Draft            SIP Connection Reuse                  May 2008


8.1.  Client Behavior

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

      For TCP and SCTP transports, the client SHOULD NOT insert the
      "alias" parameter in the topmost Via header unless conditions
      mentioned in Section 9.3 are duly considered.

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

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

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

   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.

   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:




Mahy, et al.            Expires November 14, 2008              [Page 11]

Internet-Draft            SIP Connection Reuse                  May 2008


   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

   A TCP connection, or a SCTP association accepted at the server is
   used by the server to only send responses upstream.  It SHOULD NOT be
   used to send requests.  Furthermore, if the topmost Via header of a
   request received over TCP or SCTP had an "alias" parameter in it, the
   server MUST NOT accord any semantics to this parameter and must
   behave as if the parameter was not present.

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

   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.

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

      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.



Mahy, et al.            Expires November 14, 2008              [Page 12]

Internet-Draft            SIP Connection Reuse                  May 2008


   Section 9.2 discusses the authentication steps in more detail.

   The server, if it decides to reuse the connection, MUST cache in the
   alias table the identity (or identities) of the client as they appear
   in the X.509 certificate subjectAlternativeName extension field.  The
   server 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
   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



Mahy, et al.            Expires November 14, 2008              [Page 13]

Internet-Draft            SIP Connection Reuse                  May 2008


   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 TCP and SCTP Transports

   The mechanism for reusing TLS connections SHOULD NOT be used to reuse
   TCP connections or SCTP associations because there isn't any way to
   perform the authentication step.

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

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

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

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

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



Mahy, et al.            Expires November 14, 2008              [Page 14]

Internet-Draft            SIP Connection Reuse                  May 2008


10.  Connection reuse and 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 using one IP address and port number.  If
   adequate defenses are not put in place, a connection opened to a
   downstream server on behalf of one domain may be reused to send
   requests in the backwards direction to a different domain.  The
   Destination Identity column in the alias table has been added to aid
   in such defenses.

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

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

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

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




Mahy, et al.            Expires November 14, 2008              [Page 15]

Internet-Draft            SIP Connection Reuse                  May 2008


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


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


11.  Connection Reuse and SRV Interaction

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


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


                         Figure 5: 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:







Mahy, et al.            Expires November 14, 2008              [Page 16]

Internet-Draft            SIP Connection Reuse                  May 2008


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

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


13.  Acknowledgments

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

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


14.  References

14.1.  Normative References

   [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
         Levels", RFC 2119, March 1997.

   [3]   Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
         Protocol Version 1.1", RFC 4346, April 2006.

   [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 5234, January 2008.

   [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., Lawrence, S., and A. Jeffrey, "Domain Certificates
         in the Session Initiation Protocol (SIP)",



Mahy, et al.            Expires November 14, 2008              [Page 17]

Internet-Draft            SIP Connection Reuse                  May 2008


         draft-ietf-sip-domain-certs-00 (work in progress), July 2007.

14.2.  Informational References

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

   [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., "The Session Initiation Protocol (SIP)-Specific
         Event Notification", RFC 4960, September 2007.


Authors' Addresses

   Rohan Mahy
   Plantronics

   Email: rohan@ekabal.com


   Vijay K. Gurbani (editor)
   Bell Laboratories, Alcatel-Lucent

   Email: vkg@alcatel-lucent.com


   Brett Tate
   BroadSoft

   Email: brett@broadsoft.com





Mahy, et al.            Expires November 14, 2008              [Page 18]

Internet-Draft            SIP Connection Reuse                  May 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

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


Intellectual Property

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

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

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


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Mahy, et al.            Expires November 14, 2008              [Page 19]


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