SIPPING WG                                              C. Jennings, Ed.
Internet-Draft                                             Cisco Systems
Expires: August 20, 2005                                  A. Hawrylyshen
                                                         Jasomi Networks
                                                       February 19, 2005

         SIP Conventions for UAs with Outbound Only Connections

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 20, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   Often with SIP a request can only be routed over an existing
   connection or flow, such as when there is a firewall or network
   address translation (NAT) device in the network path.  TLS is also
   affected when the user agent (UA) does not have a certificate
   suitable for mutual TLS authentication.  This draft addresses how
   user agents and proxies need to behave to work in these environments.

Jennings & Hawrylyshen    Expires August 20, 2005               [Page 1]

Internet-Draft     SIP with Outbound Only Connections      February 2005

   This work shows how existing SIP mechanisms can be used to allow the
   UA to register multiple times over different connections or flows and
   the proxies can use the instance-id in the contact header to identify
   that the multiple flows go to the same UA.  It can then choose which
   flow to use to route requests to this UA.

   This work is being discussed on the mailing list.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Conventions & Terminology  . . . . . . . . . . . . . . . . . .  4
     3.1   Definitions  . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1   Single Registrar and UA  . . . . . . . . . . . . . . . . .  5
     4.2   Multiple Connections from a User Agent . . . . . . . . . .  7
     4.3   Edge Proxies . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.1   User Agent . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.2   Registrar  . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.3   Edge Proxy . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.4   Receivers of REGISTER Requests . . . . . . . . . . . . . . 12
   6.  Grammar  . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   9.  Changes from 00 Version  . . . . . . . . . . . . . . . . . . . 14
   10.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 14
   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 14
   11.1  Normative References . . . . . . . . . . . . . . . . . . . . 14
   11.2  Informative References . . . . . . . . . . . . . . . . . . . 15
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
       Intellectual Property and Copyright Statements . . . . . . . . 17

Jennings & Hawrylyshen    Expires August 20, 2005               [Page 2]

Internet-Draft     SIP with Outbound Only Connections      February 2005

1.  Introduction

   There are many environments for SIP deployments in which the
   user-agent (UA) can form a connection to the Registrar or Proxy but
   in which the connections in the reverse sense are not possible.  This
   can happen for several reasons.  It is important to understand that
   most IP phones and and soft-phones get their network configurations
   via a host-configuration protocol such as DHCP; they typically do not
   have a useful name in DNS; and they definitely do not have a
   long-term, stable DNS name that is appropriate for binding to a
   certificate.  It is impractical for them to have a certificate that
   can be used as a client-side TLS certificate.  However, they do
   support TLS and form TLS connections to a proxy or registrar which
   the UA authenticates using TLS, and the server authenticates the UA
   using a digest challenge.

   Sometimes a firewall device between the UA and proxy or registrar
   will only allow connections in the "outbound" direction.  Similarly
   there may be a NAT that is only capable of allowing connections in
   the "outbound" direction.  It is worth noting that most UAs in the
   world are deployed behind a firewall or NAT.

   This document describes several concepts that are used to solve this
   problem using a key idea from the connection reuse draft [10]: A
   proxy that wishes to route a request to a particular AOR, say, may use any connection to Alice's UA which has
   been previously authenticated at an appropriate level to allow it to
   change the registration bindings for Alice.

   Secondly, for high reliability systems, the UA needs to keep a
   connection to the proxy or registrar that it can use at any time.
   This is achieved by having the UA keep multiple connections, referred
   to as "flows", to the proxy or registrar and using a keep alive
   mechanism on each flow so that the UA can detect when it has failed
   and establish a new one.

   The overall approach can be summarized simply: UAs use a keep alive
   mechanism to keep their flow to the proxy or registrar alive.  For
   TCP, TLS, and other connection oriented protocols this is a burst
   containing a CRLF payload, and for UDP it is a STUN request over the
   flow.  A UA can create more than one flow using multiple
   registrations for the same contact and AOR.  The instance in the
   contact is used to identify the UA that a connection is associated
   with.  A new contact parameter called flow-id is used to allow the
   proxy and registrar to tell the difference between a UA
   re-registering and registering an additional connection.  The proxies
   keep track of the "flows" or connection mappings for successful

Jennings & Hawrylyshen    Expires August 20, 2005               [Page 3]

Internet-Draft     SIP with Outbound Only Connections      February 2005

   When a proxy goes to route a message to a UA for which it has a
   mapping, it can use any one of the flows on which a successful
   registration has been completed for that contact.  A failure on a
   particular flow can be tried again on an alternate flow.

2.  Requirements

   Must be able to detect that a UA supports these mechanisms.

   Support UAs behind NATs.

   Support UAs behind firewalls.

   Support TLS to a UA without stable DNS name or IP.

   Detect failure of connection and be able to correct for this.

   Support many UAs simultaneously rebooting.

   Support a NAT rebooting or resetting.

   Support proxy farms with multiple hosts for scaling and reliability

   Minimize initial startup load on a proxy.

3.  Conventions & Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [1].

3.1  Definitions
      'Edge Proxy': An Edge Proxy is any proxy that is located
      topologically between the registering user agent and the
      'Flow': A Flow is a network protocol level connection between two
      endpoints that is represented by the network address of both ends
      and the protocol.  For TCP and UDP this would include the IP
      addresses and ports of both ends and the protocol (TCP or UDP).
      With TCP, a flow would often correspond with a single file
      descriptor in the OS.
      'Outbound Connection': An Outbound Connection is a connection
      between two network elements that can only be established by one
      party.  Typically this is due to network policy from a firewall or
      NAT device or to issues with TLS where one end does not have a
      certificate that can be used as a server certificate so cannot act
      as a TLS server.

Jennings & Hawrylyshen    Expires August 20, 2005               [Page 4]

Internet-Draft     SIP with Outbound Only Connections      February 2005

      'Third party registration ': A third party registration is defined
      in section 10.2 of RFC 3261.  It is a REGISTER request in which
      the value of the To header field is not the same as that of the
      From header field.

4.  Overview

   Several scenarios in which this technique is useful are discussed
   below, including the simple collocated registrar and proxy, a user
   agent desiring multiple connections to a resource (for redundancy for
   example), and an system that uses Edge Proxies.  This section
   explains the details of the approach while section (Section 5) has
   the exact details of how various elements handle messages.

4.1  Single Registrar and UA

   The network's topology in this example is that there is single server
   acting as a registrar and proxy, with which the user agent registers.

      |Proxy    |
       |User  |
       |Agent |

   User Agents forming only a single connection continue to register in
   the normal way but include the instance identifier as described in
   the GRUU [8] and can also add a flow-id parameter to the Contact
   header field value.  The flow-id parameters are used to allow the
   registrar to detect and avoid using invalid contacts when a UA
   reboots, as described later in this section.

   For clarity, here is an example.  Alice's UA creates a new TCP flow
   to the registrar and sends the following register.

Jennings & Hawrylyshen    Expires August 20, 2005               [Page 5]

Internet-Draft     SIP with Outbound Only Connections      February 2005

      REGISTER SIP/2.0
      Via: SIP/2.0/UDP;branch=z9hG4bK-bad0ce
      Max-Forwards: 70
      From: Bob <>;tag=d879h76
      To: Bob <>
      Call-ID: 8921348ju72je840.204
      CSeq: 1 REGISTER
      Contact: <sip:line1@>; flow-id=1;
      Content-Length: 0

   The registrar would, as usual, challenge this registration to
   authenticate the sender.  When the registrar adds an entry for this
   contact under the AOR for Bob, the registrar also needs to form a
   sublist under this contact that keeps track of the flow that received
   this registration and the flow-id value.

   Later when Alice sends a request to Bob at the registrar, it acts as
   a proxy and follows [2] to select a contact to forward the request
   to.  The proxy then looks and finds the flows that have registrations
   to this contact.  It forwards the request on that flow instead of
   trying to form a new flow to that contact.  This allows the proxy to
   forward a request to a particular contact down the same flow that did
   the registration for this AOR.  If the proxy had multiple flows that
   all went to this contact, it could choose any one of them that had
   registered for this AOR and had the same instance value as the
   selected contact.  In general, if two flows have the same flow-id
   value, the proxy would favor the most recently registered flow.  This
   is so that if a UA reboots, the proxy will prefer to use the most
   recent flow that goes to this UA instead of trying one of the old
   flows which will presumably fail.

   The keep alive mechanism needs to detect both failure of a connection
   and changes to the NAT public mapping.  When a residential NAT is
   rebooted, the UA needs to understand that its bindings are no longer
   valid and it needs to reregister.  Simply sending keep alive packets
   will not detect this failure when using UDP.  With connection
   oriented transports such as TCP or TLS, the keep alive will detect
   failure after a NAT reboot.  Connection oriented transport failures
   are detected as the UA periodically sends a CRLF over the connection;
   if the connection has failed, a connection level error will be
   reported to the UA.  A CRLF can be considered the beginning of the
   next message that will be sent and therefore this approach is
   backwards compatible with existing standards.  The TCP KEEP_ALIVE
   mechanism is not used because many operating systems do not allow
   this to be set on a per connection basis.

   The keep alive mechanism for UDP is quite different.  The UA needs to

Jennings & Hawrylyshen    Expires August 20, 2005               [Page 6]

Internet-Draft     SIP with Outbound Only Connections      February 2005

   detect when the connection is working but also when the flow
   definition has changed.  A flow definition could change because a NAT
   device in the network path reboots and the resulting pubic address
   mapping for the UA changes.  STUN [4] requests are sent over the
   connection that is being used for the UDP SIP traffic.  The proxy or
   registrar acts as a STUN server on the SIP signaling port.

   The STUN mechanism is very robust and allows the detection of a
   changed IP address.  It may also be possible to do this with OPTIONS
   messages and rport; although this approach has the advantage of being
   backwards compatible, it also significantly increases the load on the
   proxy or registrar server.

   If the UA detects that the connection has failed or that the flow
   definition has changed, it will re-register using a back-off
   mechanism described in Section 5.1 in order to provide congestion
   relief when a large number of agents simultaneously reboot.

   The registrar saves the instance id (as defined in GRUU [8]) and
   flow-id (as defined in Section 6) along with the rest of the contact
   Header.  If the instance id and flow-id are the same as a previous
   registration, the proxy or registrar can decide to fork requests to
   these contacts' registrations in serial and to choose to use the most
   recently created registration first.  This allows a UA that has
   rebooted to replace its previous registration for each flow with
   minimal impact on overall system load.

   If the TCP flow to the registrar is closed, any map entries referring
   to that flow must be removed.  Similarly, if the registration
   expires, any map entries created by it need to be removed.

   A note about the UUID: a device like a soft-phone, when first
   installed, should generate a UUID [6] and then save this in
   persistent storage for all future use.  For a device such as a hard
   phone, which will only ever have a single SIP UA present, the UUID
   can be generated at any time because it is guaranteed that no other
   UUID is being generated at the same time on that physical device.
   This means the value of the time component of the UUID can be
   arbitrarily selected to be any time less than the time when the
   device was manufactured.  A time of 0 (as shown in the example) is
   perfectly legal as long as the device knows no other UUIDs were
   generated at this time.

4.2  Multiple Connections from a User Agent

   In this example system, the logical proxy/registrar for the domain is
   running on two hosts that share appropriate state and can both
   provide registrar and proxy functionality for the domain.  The UA

Jennings & Hawrylyshen    Expires August 20, 2005               [Page 7]

Internet-Draft     SIP with Outbound Only Connections      February 2005

   will form connections to two of the physical hosts for the domain.

       | Domain            |
       | Logical Proxy/Reg |
       |                   |
       |+-----+     +-----+|
       ||Host1|     |Host2||
       |+-----+     +-----+|
            \          /
             \        /
              \      /
               \    /
              |User  |
              |Agent |

   A UA that forms two or more flows has similar behavior to a UA that
   forms a single connection but has some additional requirements.  The
   UA MAY be configured with a primary and backup outbound proxy or it
   MAY select two flows to form using the DNS selection mechanism
   described in this section.  The registration on each flow needs to
   contain the instance identifier from the GRUU mechanisms and also
   needs to add a different flow-id parameter to the Contact header so
   that the Registrar can differentiate the flows as being distinct
   connections from the same instance.  For example, the flow-id value
   might be set to 1 for the primary connection and 2 for the backup

   A UA that needs to establish multiple flows needs a way to use DNS to
   select candidate addresses for the formation of flows.  The
   recommended way to do this is to look at the DNS records resulting
   from the algorithm described in RFC 3263 [3] and select distinct
   addresses from the target set.

   Hosts that are multi-homed can avoid complications by ensuring that
   interfaces that are in separate routing domains have distinct DNS
   names for each routing domain.  Having different SRV records point to
   the same host record should also be avoided when deploying proxies.
   Multiple interfaces in a single network should either be absent from
   DNS or preferably share an address.  These guidelines will help
   prevent a UA from establishing flows that connect to the same
   resource and thereby unintentionally eliminating the desired

   When a proxy goes to route a call to a particular contact, it can use

Jennings & Hawrylyshen    Expires August 20, 2005               [Page 8]

Internet-Draft     SIP with Outbound Only Connections      February 2005

   the flow for any registration to that contact that has the same
   instance value of the selected contact.  If it detects that a flow
   has failed, it needs to remove that mapping and use the others.

4.3  Edge Proxies

   Some SIP deployments use edge proxies such that the UA sends the
   REGISTER to an edge proxy that then forwards the REGISTER to the
   Registrar.  The edge proxy can include a path header as defined in
   RFC 3327 [9] so that when the registrar later retargets a request to
   this UA, the request is routed through the edge proxy.

                |Proxy    |
                 /      \
                /        \
            +-----+     +-----+
            |Edge1|     |Edge2|
            +-----+     +-----+
               \           /
                \         /
                 \       /
                  \     /
                   \   /
                  |User  |
                  |Agent |

   These systems can use effectively the same mechanism as described in
   the previous sections but need to use the Path header.  When the edge
   proxy receives a registration, it needs to create an identifier value
   that is unique to this AOR, contact, flow, and instance-id and put
   this identifier in the path header.  This is done by putting the
   value in the user portion of a loose route in the path header.  If
   the registration succeeds, the edge proxy needs to map future
   requests that are routed to the identifier value that was put in the
   path header to the associated flow.  The edge proxy needs to ensure
   that a 200 response to a register request represents a successful
   registration and not some spoofed traffic to the edge proxy.  One way
   this can be done is by ensuring that it only pays attention to
   responses received over a TLS connection from a proxy that is
   authoritative for the domain of the registration.

   As an alternative to actually storing the state for the mapping in
   the edge proxy, the proxy can form an encrypted version of the flow

Jennings & Hawrylyshen    Expires August 20, 2005               [Page 9]

Internet-Draft     SIP with Outbound Only Connections      February 2005

   identifier and put it in the path header so that the edge proxy will
   get it back from the registrar at the time it needs it.

5.  Mechanisms

5.1  User Agent

   User Agents MUST support the the instance identifier as described in
   the GRUU [8] mechanism.  If the UA detects that the binding on a NAT
   has changed, it MUST treat this as a connection failure and
   re-register.  When registration fails due to a network problem or the
   Registrar does not respond, the UA maintains a range value for
   computing when it should next attempt to register.  This range value
   SHOULD have an initial value of 1 minute and SHOULD double after each
   consecutive failed registration attempt, up to a maximum of 30
   minutes.  When a registration fails due to network problems, the UA
   MUST randomly select a time to re-register that is between 50 and 100
   percent of the current range value.

   User Agents that form two or more connections behave similarly to
   User Agents that form single connections but also have some
   additional requirements.  All User Agents SHOULD support forming
   multiple connections.  The UA MAY be configured with a primary and
   backup outbound proxy.  It MUST support selecting at least two
   connections using the mechanism described in Location of SIP Servers
   [3].  When DNS is used, the UA finds IP addresses used for
   registration the normal way, but if it discovers more than one
   possible IP address, it SHOULD connect to two distinct addresses,
   among the possible IP addresses.  If the UA finds multiple records
   that correspond to different A or AAAA records, it SHOULD select
   address corresponding to different A or AAAA records.

   Each connection MUST contain the instance identifier from the GRUU
   mechanisms but MUST also add a distinct flow-id parameter to the
   contact header field value so that the Registrar can differentiate
   the two connections as being from the same instance but different
   connections.  The flow-id MAY be set to 1 for the primary connection
   and 2 for the backup connection.  Each time the UA is rebooted, it
   SHOULD use the same flow-id values it previously used.

   On connection oriented transports such as TCP or TLS, if no other
   traffic has been sent for 600 seconds, then the UA MUST send a CRLF
   to detect whether the connection has failed.  On UDP connections, the
   UA MUST send a STUN [4] request every 30 seconds over the same flow
   as the SIP signaling.  If the UA detects that the flow has changed,
   it MUST reregister.

   The text in this section does not apply to third party registration.

Jennings & Hawrylyshen    Expires August 20, 2005              [Page 10]

Internet-Draft     SIP with Outbound Only Connections      February 2005

   A UA doing third party registration would proceed as described in RFC

   User Agents that form flows with stream oriented protocols such as
   TCP, TLS, or SCTP SHOULD periodically send a CRLF over the connection
   to detect liveness of the flow.  It is RECOMMENDED that a CRLF be
   sent if the flow has not had any data sent or received in the
   previous 600 seconds.  The UA SHOULD not send a CRLF if data has been
   sent or received in the previous 30 seconds.

   User Agents that form flows with UDP SHOULD perform STUN requests
   over the flow every 30 seconds.  If the mapped address in the STUN
   response changes, the UA must treat this as a transport error on the
   flow.  This will cause the UA to form a new registration on a new

5.2  Registrar

   The registrar MUST check if the registration is a 3rd party
   registration.  If so it would process it normally and none of the
   other text in this section would apply.

   When a registrar receives a registration that does not contain a path
   header, it processes the registration as normal; and if the
   registration is successful, the registrar MUST store the flow-id,
   instance value and reference to the flow to a list that is maintained
   for this particular AOR and contact.  The reference to flow is the
   information it needs to send a message back to the UA over this same
   flow.  Typically it would be something like the file descriptor for
   TCP or the full source and destination addresses and ports for UDP.

   This document does not require a registrar to support the path
   header, but if registrar does there is some special processing based
   on the path header.  Specifically, when a registrar that supports
   path receives a registration that contains a path header, the
   registrar still stores the instance value and flow id but does not
   save the reference information to the flow.

   When the registrar, acting as a proxy, proxies a request to a
   particular contact, it selects a contact to use in the normal way.
   Next the registrar selects a flow to reach this contact.  It forms
   the list of possible flows by looking at the contacts registered for
   this AOR and selecting the ones that have the same instance value.
   The registrar MAY decide, when two flows have the same flow-id, to
   choose the one that registered most recently.  Once a flow is
   selected, the registrar needs to forward to that flow.  If a path
   header was used for the registration of that flow, the registrar
   populates the request in the normal way and forwards it.  If there

Jennings & Hawrylyshen    Expires August 20, 2005              [Page 11]

Internet-Draft     SIP with Outbound Only Connections      February 2005

   was no path header, then the registrar looks at the flow reference
   information for that flow and forwards the request over the same flow
   that was used to receive the registration.

   If the registrar receives a transport level error using this flow, it
   must remove the flow and any associated registration information.

5.3  Edge Proxy

   When an edge proxy receives a registration request that does not
   contain a path header, it MUST form a registration identifier that is
   unique to this flow and then include that identifier in the path
   header it adds to the registration.  This is done by inserting the
   unique identifier in the user portion of the path header URI for this
   edge proxy.

   If the edge proxy receives a request that is routed to a registration
   identifier that it has created, then it MUST forward the request on
   the flow that created the registration.  This can be implemented
   either by storing the mapping from the unique identifier to the flow
   when the identifier is created or, if the edge proxy does not wish to
   save this state information, it can take the flow reference
   information and encrypt it with a secret known only to the edge proxy
   and put it in the user portion of the path header.  Later when the
   edge proxy receives a request, it can decrypt this information and
   use it to route the request over the correct flow.

   The edge proxy MUST ensure that data sent from the edge proxy to the
   registrar or other edge proxies is integrity protected against
   attackers.  This could be achieved by using TLS between the edge
   proxy and the registrar.

5.4  Receivers of REGISTER Requests

   A device that receives register requests directly from a UA needs to
   behave as specified in this section.  Such devices would generally
   include a Registrar and and an Edge Proxy, as they both receive
   register requests directly from a UA.

   If the server receives UDP SIP requests on a given interface and
   port, it MUST also provide a limited version of the STUN server on
   the same interface and port.  Specifically it MUST support all of
   STUN with the exception that it does not need to support STUN
   requests with the changed port or changed address flag set.  This
   allows the STUN server to run with only one port and IP address.

   It is easy to demux STUN and SIP packets because the first byte of a
   STUN packet is 0 or 1 while the first byte of a SIP packet is in the

Jennings & Hawrylyshen    Expires August 20, 2005              [Page 12]

Internet-Draft     SIP with Outbound Only Connections      February 2005

   range of 'A' to 'Z'.

6.  Grammar

   This specification defines a new Contact header field parameter,
   flow-id.  The grammar for pvalue and EQUAL is obtained from RFC 3261

      contact-params = c-p-q / c-p-expires / contact-extension
      c-p-connection = "flow-id" EQUAL pvalue
                       ; defined in RFC3261

7.  IANA

   This specification defines a new Contact header field parameter
   called flow-id, as per the registry created by [5].  The required
   information is as follows:

      Header field in which the parameter can appear: Contact

      Name of the Parameter: flow-id

      RFC Reference: RFC AAAA [NOTE TO IANA: Please replace AAAA with
                               the RFC number of this specification.]

8.  Security Considerations

   One of the key security concerns in this work is making sure that an
   attacker cannot hijack the sessions of a valid user and cause all
   calls destined to that user to be sent to the attacker.

   The simple case is when there are no edge proxies.  In this case, the
   only time an entry can be added to the routing for a given AOR is
   when the registration succeeds.  SIP protects against attackers being
   able to successfully register, and this scheme relies on that
   security.  Some implementers have considered the idea of just saving
   the instance without relating it to the AOR with which it registered.
   This idea will not work because an attacker's UA can impersonate a
   valid user's instance value and hijack that user's calls.

   The more complex case involves one or more edge proxies.  The only
   time an edge proxy will route over a particular flow is when it has
   received a route header that has the instance information it has

Jennings & Hawrylyshen    Expires August 20, 2005              [Page 13]

Internet-Draft     SIP with Outbound Only Connections      February 2005

   created.  An incoming request would have gotten this information from
   the registrar.  The registrar will only save this information for a
   given AOR if the registration for the AOR has been successful; and
   the registration will only be successful if the UA can correctly
   authenticate.  Even if an attacker has spoofed some bad information
   in the path header sent to the registrar, the attacker will not be
   able to get the registrar to accept this information for an AOR that
   does not belong to the attacker.  The registrar will not hand out
   this bad information to others, and others would not be misled into
   contacting the attacker.

9.  Changes from 00 Version

   Changed the behavior of the proxy so that it does not automatically
   remove registrations with the same instance and flow-id but instead
   just uses the most recently created registration first.

   Changed the connection-id to flow-id.

   Fixed expiry of edge proxies and rewrote mechanism section to be

10.  Acknowledgments

   Rohan Mahy had the insight key to this draft, that registration can
   be used to authorize connection reuses.  Dave Oran came up with the
   idea of using the most recent registration first in the proxy.  The
   TCP design team consisting of Chris Boulton, Scott Lawrence, Rajnish
   Jain, Vijay K.  Gurbani, and Ganesh Jayadevan provided input.
   Additionally, many of the concepts here originated at a connection
   reuse meeting at IETF 60 that included Jon Peterson, Jonathan
   Rosenberg, Paul Kyzivat and Rohan Mahy.

11.  References

11.1  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

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

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

   [4]  Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN -

Jennings & Hawrylyshen    Expires August 20, 2005              [Page 14]

Internet-Draft     SIP with Outbound Only Connections      February 2005

        Simple Traversal of User Datagram Protocol (UDP) Through Network
        Address Translators (NATs)", RFC 3489, March 2003.

   [5]  Camarillo, G., "The Internet Assigned Number Authority (IANA)
        Header Field Parameter Registry for the Session Initiation
        Protocol (SIP)", draft-ietf-sip-parameter-registry-02 (work in
        progress), June 2004.

   [6]  Mealling, M., "A UUID URN Namespace", draft-mealling-uuid-urn-03
        (work in progress), March 2004.

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

   [8]  Rosenberg, J., "Obtaining and Using Globally Routable User Agent
        (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)",
        draft-ietf-sip-gruu-02 (work in progress), July 2004.

   [9]  Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
        Extension Header Field for Registering Non-Adjacent Contacts",
        RFC 3327, December 2002.

11.2  Informative References

   [10]  Mahy, R., "Connection Reuse in the Session Initiation Protocol
         (SIP)", draft-ietf-sip-connect-reuse-02 (work in progress),
         July 2004.

   [11]  Mahy, R., "Requirements for Connection Reuse in the Session
         Initiation Protocol (SIP)",
         draft-ietf-sipping-connect-reuse-reqs-00 (work in progress),
         October 2002.

Authors' Addresses

   Cullen Jennings (editor)
   Cisco Systems
   170 West Tasman Drive
   Mailstop SJC-21/2
   San Jose, CA  95134

   Phone: +1 408 902-3341

Jennings & Hawrylyshen    Expires August 20, 2005              [Page 15]

Internet-Draft     SIP with Outbound Only Connections      February 2005

   Alan Hawrylyshen
   Jasomi Networks
   310, 602 - 11 Ave SW
   Calgary, Alberta  T2R 1J8

   Phone: +1 866 617 8647

Jennings & Hawrylyshen    Expires August 20, 2005              [Page 16]

Internet-Draft     SIP with Outbound Only Connections      February 2005

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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


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

Jennings & Hawrylyshen    Expires August 20, 2005              [Page 17]