A Session Initiation Protocol (SIP) Response Code for Interactive Connectivity Establishment (ICE) Failures
draft-rosenberg-sip-ice-error-code-01

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 August 26, 2008.

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.

Table of Contents

1.  Introduction
2.  Terminology
3.  UAC Behavior
4.  UAS Behavior
5.  Proxy Behavior
6.  562 (Connectivity Checks Failed) Response Code
7.  Security Considerations
    7.1.  Outside Attacks
    7.2.  Insider Attacks
8.  IANA Considerations
9.  References
    9.1.  Normative References
    9.2.  Informative References
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

Interactive Connectivity Establishment (ICE) [I‑D.ietf‑mmusic‑ice] (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” October 2007.) defines an extension to the offer/answer model [RFC3264] (Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with Session Description Protocol (SDP),” June 2002.) used by the Session Initiation Protocol (SIP) [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.). 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] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) 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] (Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, “Session Traversal Utilities for (NAT) (STUN),” July 2008.).

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:

• 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] (Perreault, S. and J. Rosenberg, “TCP Candidates with Interactive Connectivity Establishment (ICE),” October 2009.) which would allow the RTP traffic to flow over TCP.
• 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.
• 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.
• 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.

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] (Schulzrinne, H., Oran, D., and G. Camarillo, “The Reason Header Field for the Session Initiation Protocol (SIP),” December 2002.) 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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [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] (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” October 2007.), 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] (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” October 2007.), 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 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 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

9.2. Informative References

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2008).

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

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

Intellectual Property

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

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

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