SIPPING WG                                                       R. Mahy
Internet-Draft                                       Cisco Systems, Inc.
Expires: April 1, 2003                                          Oct 2002


  Requirements for Connection Reuse in the Session Initiation Protocol
                                 (SIP)
              draft-ietf-sipping-connect-reuse-reqs-00.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 April 1, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

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
   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 presents
   requirements for addressing this shortcoming, and separately proposes
   an example mechanism which addresses this deficiency.



Mahy                     Expires April 1, 2003                  [Page 1]


Internet-Draft           Connection Reuse Reqs                  Oct 2002


Table of Contents

   1.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction and Problem Statement . . . . . . . . . . . . . .  3
   3.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Overview of Proposed Mechanism . . . . . . . . . . . . . . . .  6
   4.1 Authorizing an alias request . . . . . . . . . . . . . . . . .  7
   4.2 Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
       Normative References . . . . . . . . . . . . . . . . . . . . .  9
       Informational References . . . . . . . . . . . . . . . . . . .  9
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11




































Mahy                     Expires April 1, 2003                  [Page 2]


Internet-Draft           Connection Reuse Reqs                  Oct 2002


1. Conventions

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

2. Introduction and Problem Statement

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

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

   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
   (routed from the target of the original connection toward the
   originator of the original connection) 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     |
          |           |<-----------------------|           |
          +-----------+                        +-----------+

   This extra pair of connections can result in potential scaling and
   performance problems.  For example, each new connection using TLS
   requires a TCP 3-way handshake, a handful of round-trips to establish
   TLS, and (typically) expensive asymetric authentication and key



Mahy                     Expires April 1, 2003                  [Page 3]


Internet-Draft           Connection Reuse Reqs                  Oct 2002


   generation algorithms, and certificate verification.   This
   effectively doubles the load on each entity.  Setting up a second
   connection can also cause excessive delay (especially in networks
   with long round-trip times) for subsequent requests, even requests in
   the context of an existing dialog (for example a reINVITE or BYE
   after an initial INVITE, or a NOTIFY after a SUBSCRIBE [8] or a REFER
   [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.

      INVITE ->   create connection 1
      <- 200      response over connection 1
      ACK ->      reuse connection 1

      <- BYE      create connection 2
      -> 200      response over connection 2

   ReINVITEs are expected to be handled automatically and rapidly in
   order to avoid media and session state from being out of step.  If a
   reINVITE 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 3pcc
   [7]) use many reINVITEs.

   Consider also a call flow where a handheld organizer sends a REFER
   request which establishes a dialog to a SIP phone.  Typically this
   would require a second connection back to the handheld to be
   established.

      REFER ->               connection 1
      <- 202                 connection 1
      <- NOTIFY              connection 2
      200 ->                 connection 2
                 INVITE ->
                 <- 200
      <- NOTIFY              connection 2
      200 ->                 connection 2

   Likewise when clusters or farms of cooperating SIP servers (for
   example proxy servers) are configured together, SIP entities have no
   way to prefer a server with an existing connection.  For example,
   Proxy server B has no mechanism to choose an existing connection with
   Proxy cluster A.




Mahy                     Expires April 1, 2003                  [Page 4]


Internet-Draft           Connection Reuse Reqs                  Oct 2002


          +-----------+
          |           |
          |   Proxy   |
          |    A1     |                        +-----------+
          |           |                        |           |
          +-----------+                        |   Proxy   |
          +-----------+ 8293              5061 |     B     |
          |           |----------------------->|           |
          |   Proxy   |                        +-----------+
          |     A2    |
          |           |
          +-----------+

   As a result, Proxy B might open a new connection to another proxy
   server for requests sent in the opposite direction.

          +-----------+
          |           |
          |   Proxy   |
          |     A1    | 5061              9741 +-----------+
          |           |<.......................|           |
          +-----------+                        |   Proxy   |
          +-----------+ 8293              5061 |     B     |
          |           |----------------------->|           |
          |   Proxy   |                        +-----------+
          |     A2    |
          |           |
          +-----------+

   The rules for handling the Transport layer described in Section 18 of
   SIP [1] do not associate incoming connections with the listening port
   which corresponds to the same SIP entity.  If the Tranport layer had
   some way to associate these connections, then request and responses
   originated from either node could reuse existing connections as shown
   below.

          +-----------+                        +-----------+
          |           |                        |           |
          |   Node A  | 8293              5061 |   Node B  |
          |           |<======================>|           |
          |           |                        |           |
          +-----------+                        +-----------+


3. Requirements

   1.  A connection sharing mechanism SHOULD allow SIP entities to reuse
       existing connections for requests and repsonses originated from



Mahy                     Expires April 1, 2003                  [Page 5]


Internet-Draft           Connection Reuse Reqs                  Oct 2002


       either peer in the connection.

   2.  A connection sharing mechanism SHOULD allow SIP entities to reuse
       existing connections with closely coupled nodes which act as a
       single SIP entity (for example a cluster of nodes acting as a
       proxy server).

   3.  A connection sharing mechanism MUST NOT require UACs (clients) to
       send all traffic from well-know SIP ports.

   4.  A connection sharing mechanism MUST NOT require configuring
       ephemeral port numbers in DNS.

   5.  A connection sharing mechanism MUST prevent unauthorized
       hijacking of other connections.


4. Overview of Proposed Mechanism

   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 originator of the request wants to create a transport layer
   alias, so that the sent-by address maps to the current connection.

   Assuming the Via header field value shown below from the most recent
   request arrived over a connection from 60.54.32.1 port 8241:


      Via: SIP/2.0/TLS 60.54.32.1:5061;branch=z9hG4bKa7c8dze ;alias

   The transport layer would create an alias in order to get to:

       60.54.32.1:5061  send on->  connection with 60.54.32.1:8241

   Likewise when clusters or farms of cooperating SIP servers (for
   example proxy servers) are configured together, the proposed
   mechanism allows a SIP entity to select a server with an existing
   connection.  With the proposed mechanism, Proxy B would send requests
   for Proxy cluster A to node A2 with whom it shares an existing
   connection.











Mahy                     Expires April 1, 2003                  [Page 6]


Internet-Draft           Connection Reuse Reqs                  Oct 2002


          +-----------+
          |           |
          |   Proxy   |
          |     A1    |                        +-----------+
          |           |                        |           |
          +-----------+                        |   Proxy   |
          +-----------+ 8293              5061 |     B     |
          |           |<======================>|           |
          |   Proxy   |                        +-----------+
          |     A2    |
          |           |
          +-----------+

   For example, on receipt of a message with the following topmost Via
   header:

      Via: SIP/2.0/TLS host-a.atlanta.com;branch=z9hG4bK7c8dze ;alias

   The transport layer would create an alias in order to get to:

      host-a.atlanta.com:5061 send on-> connection with 60.54.32.1:8241

   The alias would be treated as a request which asks the transport
   layer to create an alias (named by the sent-by parameter which could
   be a hostname) which points to the alias target (the current
   connection)

   This mechanism is fully backwards compatible with existing
   implementations.  If the proposed Via parameter is not understood by
   the recipient, it will be ignored and the two implementations will
   revert to current behavior (two connections).

4.1 Authorizing an alias request

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

   To correctly authorize an alias, both the active connection and the
   alias need to authenticate using the same credentials.  This could be
   accomplished using one of two mechanisms.  The first (and preferred)
   mechanism is using TLS mutual authentication, such that the
   subjectAltName of the originator certificate corresponds to both the
   current connection and the target address of the alias.   The Via
   sent-by address needs to be within the scope protected by the
   certificate presented by the originator during TLS mutual
   authentication and the received IP address needs be a valid IP



Mahy                     Expires April 1, 2003                  [Page 7]


Internet-Draft           Connection Reuse Reqs                  Oct 2002


   address for the sent-by host or hosts.  In other words, the sent-by
   address and port combination MUST be resolvable from the
   subjectAltName of the originator certificate, and the received IP
   address MUST be resolvable from the sent-by address.  This is in
   addition to other requirements for TLS authentication and
   authorization discussed in SIP [1] and Locating SIP Servers [6].

   The second mechanism is to accept an alias if the target address of
   the alias is equivalent (using SIP comparison rules) to a valid
   Contact already registered by the same user.  This user could be
   authenticated through any SIP or TLS mechanism (ex: user certificate,
   or Kerberos [10]), but would typically use Digest authentication [5].
   For example, if Alice registers a Contact of 123.45.67.89:5061, she
   could inform Proxy 1 of the existence of a connection to her from
   Proxy 2.  This would allow her to preemptively originate TLS
   connections, as her user agent may not have access to a site
   certificate with which to authenticate incoming TLS connections.

                                               +-----------+
                                               |           |
                                               |   Proxy   |
          +-----------+ 8672              5061 |     1     |
          |           |----------------------->|           |
          |   Alice   |                        +-----------+
          |           |                        +-----------+
          |           |----------------------->|           |
          +-----------+ 8293              5061 |   Proxy   |
                                               |     2     |
                                               |           |
                                               +-----------+


4.2 Formal Syntax

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

      via-params = via-ttl / via-maddr / via-received / via-branch /
                   via-alias / via-extension

      via-alias  = "alias"


5. Security Considerations

   This document presents requirements and a sample mechanism for
   reusing existing connections easily.  Connection reuse presents many



Mahy                     Expires April 1, 2003                  [Page 8]


Internet-Draft           Connection Reuse Reqs                  Oct 2002


   opportunities for abuse and hijacking, but these attacks can be
   prevented if the guidelines in the authorization section are
   followed.

6. IANA Considerations

   This document introduces no additional considerations for IANA.

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

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", BCP 14, RFC 2119, March 1997.

   [3]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

   [4]  Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
        P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
        1999.

   [5]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
        Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
        Basic and Digest Access Authentication", RFC 2617, June 1999.

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

Informational References

   [7]   Rosenberg, J., Schulzrinne, H., Camarillo, G. and J. Peterson,
         "Best Current Practices for Third Party Call Control in the
         Session  Initiation Protocol", draft-ietf-sipping-3pcc-02 (work
         in progress), June 2002.

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

   [9]   Sparks, R., "The SIP Refer Method", draft-ietf-sip-refer-06



Mahy                     Expires April 1, 2003                  [Page 9]


Internet-Draft           Connection Reuse Reqs                  Oct 2002


         (work in progress), July 2002.

   [10]  Kohl, J. and B. Neuman, "The Kerberos Network Authentication
         Service (V5)", RFC 1510, September 1993.

   [11]  Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
         H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
         "Stream Control Transmission Protocol", RFC 2960, October 2000.


Author's Address

   Rohan Mahy
   Cisco Systems, Inc.
   101 Cooper Street
   Santa Cruz, CA  95060
   USA

   EMail: rohan@cisco.com
































Mahy                     Expires April 1, 2003                 [Page 10]


Internet-Draft           Connection Reuse Reqs                  Oct 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

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



















Mahy                     Expires April 1, 2003                 [Page 11]