SIPPING WG C. Jennings, Ed.
Internet-Draft Cisco Systems
Expires: April 18, 2005 A. Hawrylyshen, Ed.
Jasomi Networks
October 18, 2004
SIP Conventions for Connection Usage
draft-jennings-sipping-outbound-00
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I 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.
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 18, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
SIP has many situations where a request can only be routed over an
existing connection. This can arise in cases with firewall or
network address translation (NAT) devices in the network path, over
both UDP and TCP. 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, and addresses keep-alive and DNS configuration
issues required for high reliability connections in situations where
Jennings & Hawrylyshen Expires April 18, 2005 [Page 1]
Internet-Draft SIP with Outbound Only Connections October 2004
the UA can form connections to the proxy but the reverse is not
generally true.
This work is being discussed on the sipping@ietf.org mailing list.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4
3.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
4. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1 Single Registrar and UA . . . . . . . . . . . . . . . . . 5
4.2 Multiple Connections from a User Agent . . . . . . . . . . 7
4.3 Edge Proxies . . . . . . . . . . . . . . . . . . . . . . . 7
4.4 Edge Proxies and Redirection . . . . . . . . . . . . . . . 8
5. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1 User Agent . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2 Registrar / Proxy . . . . . . . . . . . . . . . . . . . . 9
5.3 Edge Proxy . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 11
10.2 Informative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 13
Jennings & Hawrylyshen Expires April 18, 2005 [Page 2]
Internet-Draft SIP with Outbound Only Connections October 2004
1. Introduction
There are many environments for SIP deployments where the user-agent
(UA) can form a connection to the Registrar or Proxy but the
connections in the reverse sense are not generally possible. This
can happen for several reasons. It is important to understand that
most IP phones and and soft-phones get their network configuration
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 not practical 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 which the UA
authenticates using TLS and the Proxy authenticates the UA using a
digest challenge.
There may be a firewall device between the UA and Proxy that only
allows 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 [9]: A Proxy
that wishes to route a request to a particular AOR, say
alice@example.com, may use any connection to Alice's UA which had
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 that the Proxy can use at any time. This is
achieved by having the UA keep multiple connections, referred to as
"flows", to the Proxy 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 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 id in the contact is used to identify
the UA that a connection is associated with. A new contact parameter
called connection-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 registrations.
When a proxy goes to route a message to a UA for which it has a
Jennings & Hawrylyshen Expires April 18, 2005 [Page 3]
Internet-Draft SIP with Outbound Only Connections October 2004
mapping, it can use any one of the flows on which a successful
registration was completed for that contact. A failure on a
particular flow can be retried on an alternate flow.
2. Requirements
Must be able to detect that a UA supports these mechanisms.
Support UA behind NATs.
Support UA behind firewalls.
Detect failure of connection and be able to correct for this.
Support TLS to UA without stable DNS name or IP.
Support many UAs simultaneously rebooting.
Support a NAT rebooting or resetting.
Support Proxy farms with multiple hosts for scaling and reliability
purposes.
Minimize initial start up load on a proxy (sort of apple pie).
3. Conventions & 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 [1].
3.1 Definitions
'Edge Proxy': An Edge Proxy is any proxy that is located
topologically between the registering user agent and the
registrar.
'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 IP addresses
and ports of both ends and the protocol (TCP or UDP).
'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 it is due 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 April 18, 2005 [Page 4]
Internet-Draft SIP with Outbound Only Connections October 2004
4. Approach
Several scenarios where this technique is useful are discussed below,
including the simple collocated Registrar - Proxy, a user agent
desiring multiple connections to a resource (for redundancy for
example) and Edge Proxy connection examples. 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
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 connection-id parameter with a value
to the Contact header field value. These are used to allow the
registrar to detect and remove invalid contacts when a UA reboots and
described later in this section.
For clarity, here is an example. Alice's UA creates a new TCP flow
to the proxy and sends the following register.
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK-bad0ce
Max-Forwards: 70
From: Alice <sip:alice@example.com>;tag=d879h76
To: Alice <sip:alice@example.com>
Call-ID: 8921348ju72je840.204
CSeq: 1 REGISTER
Contact: <sip:line1@192.168.0.2>; connection-id=1;
;+sip.instance="<urn:uuid:00000000-0000-0000-0000-000A95A0E128>"
Content-Length: 0
The proxy would challenge this registration as normal to authenticate
the sender. When the registrar adds an entry for this contact under
the AOR for Alice, the registrar also needs to form a sublist under
this contact that keeps track of the flow that received this
registration and the connection-id value.
Later when Bob sends a request to Alice at the proxy, the proxy
follows normal rules from [2] to select a contact to send it 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 connection to that contact. This allows the proxy to
forward a request to a particular contact down the same flow that did
the registration for that contact.
Jennings & Hawrylyshen Expires April 18, 2005 [Page 5]
Internet-Draft SIP with Outbound Only Connections October 2004
The keep alive mechanism needs to detect both failure of a connection
and when the NAT public mapping has changed. 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 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
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
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 increases the load on the proxy server
significantly.
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
connection-id (as defined in Section 6) along with the rest of the
contact Header. If the instance id and connection-id are the same as
a previous registration, the previous mapping is replaced on a
successful registration response. 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
Jennings & Hawrylyshen Expires April 18, 2005 [Page 6]
Internet-Draft SIP with Outbound Only Connections October 2004
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.
4.2 Multiple Connections from a 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 MUST
contain the instance identifier from the GRUU mechanisms and MUST
also add a different connection-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 connection-id
value might be set to 1 for the primary connection and 2 for the
backup connection.
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 look at the DNS records resulting from
the algorithm described in [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 considered in the implementation
of a selection mechanism. 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 redundancy.
When a proxy goes to route a call to a particular contact, it can use
the flow for any registration to that contact. If it detects that
one has failed, it needs to remove that one and use the others.
4.3 Edge Proxies
Some registration services are distributed so that there is an edge
proxy between the UA and registrar. These systems can use
effectively the same mechanism as described above but need to use the
Jennings & Hawrylyshen Expires April 18, 2005 [Page 7]
Internet-Draft SIP with Outbound Only Connections October 2004
Path header. The edge proxy keeps a similar map. When the edge
proxy receives a registration, it needs to create an identifier value
that is unique to this AOR, contact, connection-id, 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
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.
4.4 Edge Proxies and Redirection
Still work TODO here ... If Alice calls Bob, the Registrar for Bob
can send a 302 redirecting Alice to Bob's edge proxy. TODO show how
the path header that the edge proxy put in the Register gets copied
to Alice and returned to the edge proxy and thus the whole thing
works out fine.
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.
A User Agent that forms two or more connections has similar behavior
to a User Agent that forms single connections but has 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
Jennings & Hawrylyshen Expires April 18, 2005 [Page 8]
Internet-Draft SIP with Outbound Only Connections October 2004
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 of the possible IP
addresses.
Each connection MUST contain the instance identifier from the GRUU
mechanisms but MUST also add a distinct connection-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 connection-id MAY be set to 1 for the
primary connection and 2 for the backup connection.
On connection oriented transports such as TCP or TLS, if no other
traffic has been sent for 600 (TODO 30 or 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.
5.2 Registrar / Proxy
When a registrar receives a registration over a particular flow that
contains an instance identifier and connection id, it processes the
registration as normal, and if it is successful, it MUST append the
connection-id and reference to the flow to a list that is maintained
for this particular AOR and contact. If the list already has an
entry with the same connection-id, the registrar MUST replace the
previous entry with the current one.
If the registrar proxies a request to a particular contact, it MUST
use one of the flows it has saved for this contact. If it detects a
transport failure on this flow, it MUST remove the entry for that
flow from the list.
5.3 Edge Proxy
When an edge proxy receives a registration request, it MUST form a
registration identifier that is unique to this AOR and contact and
include that identifier in the path header it adds to the
registration.
When an edge proxy receives a 200 response to a registration it MUST
ensure that this response came from the edge proxy or registrar that
the edge proxy sent the request to. This can be accomplished using
mutual TLS or pre-configuring the network such that only the
registrar can send traffic to the side of the edge proxy that accepts
the 200. Once the 200 is determined to be a valid response for the
Jennings & Hawrylyshen Expires April 18, 2005 [Page 9]
Internet-Draft SIP with Outbound Only Connections October 2004
request, the edge proxy MUST append the connection id and a reference
to the flow on which the request was received to a list that is for
this particular AOR, contact and instance id. If the list already
has an entry with the same connection id, it MUST replace that entry.
If the edge proxy receives a request that is routed to a registration
identifier that it created, then it MUST forward the request on one
of the flows it has saved for this contact. If it detects a
transport failure on this flow, it MUST remove the entry for that
flow from the list.
6. Grammar
This specification defines a new Contact header field parameter,
connection-id. The grammar for pvalue and EQUAL is obtained from RFC
3261 [2].
contact-params = c-p-q / c-p-expires / contact-extension
c-p-connection
c-p-connection = "connection-id" EQUAL pvalue
; defined in RFC3261
7. IANA
This specification defines a new Contact header field parameter
called connection-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: connection-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 can not hijack the sessions of a valid user and cause all
calls destined to that user to be sent to the attacker instead.
The simple case to look at is when there are no edge proxies. In
this case, the only time an entry can be added to the routing for a
Jennings & Hawrylyshen Expires April 18, 2005 [Page 10]
Internet-Draft SIP with Outbound Only Connections October 2004
given AOR is when the registration succeeds. SIP protects against
attackers being able to successfully register, and this scheme relies
on that security.
The more complex case involves one or more edge proxies. This case
is similar to the simple proxy case in that the only time a table is
updated is when there has been a valid registration for that AOR. It
is critical that the edge proxy only use a 200 that came from the
registrar to decide that the registration was valid. An attacker
could send a bad registration and also spoof a 200 to this
registration, which would make the attack look like a valid
registration to the edge proxy. This would allow the attacker to
hijack an arbitrary connection.
9. Acknowledgments
Rohan Mahy had the insight key to this draft, that registration can
be used to authorize connection reuses. 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.
10. References
10.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 -
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
Jennings & Hawrylyshen Expires April 18, 2005 [Page 11]
Internet-Draft SIP with Outbound Only Connections October 2004
(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.
10.2 Informative References
[9] Mahy, R., "Connection Reuse in the Session Initiation Protocol
(SIP)", draft-ietf-sip-connect-reuse-02 (work in progress),
July 2004.
[10] 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
USA
Phone: +1 408 902-3341
EMail: fluffy@cisco.com
Alan Hawrylyshen (editor)
Jasomi Networks
310, 602 - 11 Ave SW
Calgary, Alberta T2R 1J8
Canada
Phone: +1 866 617 8647
EMail: alan@jasomi.com
Jennings & Hawrylyshen Expires April 18, 2005 [Page 12]
Internet-Draft SIP with Outbound Only Connections October 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jennings & Hawrylyshen Expires April 18, 2005 [Page 13]