SIP J. Rosenberg
Internet-Draft Cisco
Intended status: Standards Track November 10, 2007
Expires: May 13, 2008
A Session Initiation Protocol (SIP) Response Code for Interactive
Connectivity Establishment (ICE) Failures
draft-rosenberg-sip-ice-error-code-00
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 May 13, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Interactive Connectivity Establishment (ICE) defines an extension to
the offer/answer model used by the Session Initiation Protocol (SIP).
This extension allows endpoints to traverse firewalls and NATs.
However, in cases where highly restrictive firewalls exist, or where
network failures have occurred, ICE may not be able to successfully
find a media path. This document provides an error response code
that can be used with SIP in these cases.
Rosenberg Expires May 13, 2008 [Page 1]
Internet-Draft ICE Error Code November 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 5
6. 562 (Connectivity Checks Failed) Response Code . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7.1. Outside Attacks . . . . . . . . . . . . . . . . . . . . . . 5
7.2. Insider Attacks . . . . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Rosenberg Expires May 13, 2008 [Page 2]
Internet-Draft ICE Error Code November 2007
1. Introduction
Interactive Connectivity Establishment (ICE) [I-D.ietf-mmusic-ice]
defines an extension to the offer/answer model [RFC3264] used by the
Session Initiation Protocol (SIP) [RFC3261]. This extension allows
endpoints to traverse firewalls and NATs. ICE functions by having
each endpoint include a set of candidate IP addresses and ports in
their Session Description Protocol (SDP) [RFC4566] messages. Once
the candidates have been exchanged in the offer/answer procedures,
each endpoint begins a set of connectivity checks. These
connectivity checks are end-to-end "pings" utilizing the Session
Traversal Utilities for NAT (STUN) Protocol
[I-D.ietf-behave-rfc3489bis].
Once connectivity checks succeed, the associated candidates can be
used for the exchange of media. Very frequently, a particular
connectivity check will fail (usually through timeout). This happens
when the candidate is not reachable by the peer (as is the case with
private addresses), or a NAT or firewall prevents the peer from
reaching the candidate. In such cases, lower priority connectivity
checks, typically through a relay server, will succeed, allowing
media to flow.
However, in even more severe environments, none of the connectivity
checks will succeed. Some of the cases where this can happen
include:
o One of the users is behind a firewall that blocks all UDP traffic,
and the users are not utilizing the ICE extensions for TCP
[I-D.ietf-mmusic-ice-tcp] which would allow the RTP traffic to
flow over TCP.
o There is a firewall that is allowing UDP, but only to specific IP
addresses or ports (such as DNS), and the media ports are not
open. In addition, ICE-tcp is not being utilized.
o There has been a network failure, such that each party can reach
the SIP server, but there is no IP path directly between the
endpoints.
o There is severe network congestion, resulting in high packet loss
through the duration of the connectivity checks. Consequently,
all of the STUN requests or responses were dropped, and all checks
timed out.
In such cases, ICE recommends that the controlling agent terminates
the session. This can be done by sending a BYE, CANCELing the
session, or rejecting it with any error response code.
Rosenberg Expires May 13, 2008 [Page 3]
Internet-Draft ICE Error Code November 2007
However, it is extremely useful for diagnostic purposes to be able to
know that the reason for the termination of the session was that ICE
failed. SIP providers could use this information to track overall
ICE effectiveness, and to perform off-line diagnostics for those
cases to determine why ICE did not succeed. Endpoints could use this
information to inform the user that the call failed due to network
error conditions, which would allow the user to retry later, open a
customer support case, or other appropriate action.
To meet this need, this specification defines a new SIP error
response code, 562 (Connectivity Checks Failed). This can be used in
SIP responses or within the Reason header field [RFC3326] of CANCEL
or BYE requests, depending on when in the dialog the ICE checks fail.
2. 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 [RFC2119].
3. UAC Behavior
If the User Agent Client (UAC) is acting as the controlling agent in
an ICE session, and according to the rules in Section 8.1.2 of
[I-D.ietf-mmusic-ice], the state of all check lists is Failed, the
agent is supposed to terminate the session. If the state of the SIP
dialog is early, the agent SHOULD send a CANCEL request, and it
SHOULD include a Reason header field with the protocol of "SIP" and a
cause of 562. If the state of the SIP dialog is confirmed, the UAC
SHOULD send a BYE request, and it SHOULD include a Reason header
field with the protocol of "SIP" and a cause of 562.
If the UAC receives a response to its initial INVITE with a response
code of 562 (Connectivity Checks Failed), it MAY inform the user that
the session has failed due to IP network connectivity problems.
Beyond that, the 562 response code is treated like a 500 response.
The UAC can retry its request at a later time.
4. UAS Behavior
If the User Agent Server (UAS) is acting as the controlling agent in
an ICE session, and according to the rules in Section 8.1.2 of
[I-D.ietf-mmusic-ice], the state of all check lists is Failed, the
agent is supposed to terminate the session. If the state of the SIP
dialog is early, the agent SHOULD send a 562 (Connectivity Checks
Rosenberg Expires May 13, 2008 [Page 4]
Internet-Draft ICE Error Code November 2007
Failed) response to the outstanding INVITE request that initiated the
session. It SHOULD NOT include a Retry-After header field in the
response. There is not normally any way for a UAS to know when a
future attempt might succeed.
5. Proxy Behavior
A proxy receiving a 562 (Connectivity Checks Failed) response code to
an initial INVITE request MAY retry the request on an alternate
destination. However, it is RECOMMENDED that it do this only if it
has knowledge or reason to believe that the alternate destination is
more likely to successfully complete a connectivity check with the
UAC. Deployers should also keep in mind that the 562 will only be
sent after all of the checks have failed, and thus will arrive some
time after the original INVITE. There will seldom be time to try
several or even one additional alternate destinations before the
originating caller gives up.
It is RECOMMENDED that proxies which support logging and diagnostic
facilities make note of the 562 code in responses and in the Reason
header field of CANCEL and BYE requests, and log them for purposes of
debugging and tracking the results of ICE deployments.
6. 562 (Connectivity Checks Failed) Response Code
This response indicates that the INVITE request could not be
completed because connectivity checks utilizing ICE failed for the
session. Its default reason phrase is (Connectivity Checks Failed).
7. Security Considerations
7.1. Outside Attacks
A Man-in-the-middle could send this response code to prematurely
terminate a session before checks complete. However, a new response
code is not required for that; an attacker could use an existing
response code. Since, functionally, this response code results in
the same behavior in a UAC, UAS and proxy as any other 5xx response
code, the 562 response code does not introduce any new considerations
for outsider attacks.
7.2. Insider Attacks
A malicious user controlling a UA could send 562 error responses
prematurely, before ICE actually completes. This would cause the
Rosenberg Expires May 13, 2008 [Page 5]
Internet-Draft ICE Error Code November 2007
session to fail, but that would affect only the attacker. However,
if the SIP provider is utilizing the 562 error code to track
deployments of ICE, an attacker could skew the results of the log
analysis. In a large scale deployment, the attacker would need to
compromise a large number of endpoints in order to be able to skew
statistics. However, if the provider initiates diagnostic procedures
(such as investigation by IT personnel) when logs show a 562, the
attacker would cause the provider to expend human resources tracking
down non-existent problems. This is similar to a human sending
emails to tech support reporting non-existing bugs.
These attacks cannot be prevented by any cryptographic means.
Rather, providers should track the relative frequency of 562 codes
from specific users of the system, and consider them as part of the
fraud systems typically in place within provider networks. Unusually
high occurrence of 562 codes, especially when investigations
indicated no reason for the ICE failures, should be considered
suspect. However, frequency of 562 responses alone is not sufficient
cause for fraud; a user may be behind a highly restrictive NAT and
therefore all or most of their calls may actually be failing.
8. IANA Considerations
This section registers a new SIP response code according to the
procedures of RFC 3261.
RFC Number: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the
RFC number of this specification]]
Response Code Number: 562
Default Reason Phrase: Connectivity Checks Failed
9. References
9.1. Normative References
[RFC3261] 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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-mmusic-ice]
Rosenberg Expires May 13, 2008 [Page 6]
Internet-Draft ICE Error Code November 2007
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-17 (work in progress), July 2007.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Huitema, C., Mahy, R., Matthews, P., and D.
Wing, "Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-08 (work in progress),
July 2007.
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
Header Field for the Session Initiation Protocol (SIP)",
RFC 3326, December 2002.
9.2. Informative References
[I-D.ietf-mmusic-ice-tcp]
Rosenberg, J., "TCP Candidates with Interactive
Connectivity Establishment (ICE",
draft-ietf-mmusic-ice-tcp-04 (work in progress),
July 2007.
Author's Address
Jonathan Rosenberg
Cisco
Edison, NJ
US
Phone: +1 973 952-5000
Email: jdrosen@cisco.com
URI: http://www.jdrosen.net
Rosenberg Expires May 13, 2008 [Page 7]
Internet-Draft ICE Error Code November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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).
Rosenberg Expires May 13, 2008 [Page 8]