TOC 
SIPJ. Rosenberg
Internet-DraftCisco
Intended status: Standards TrackFebruary 23, 2008
Expires: August 26, 2008 


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




 TOC 

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:

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.



 TOC 

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



 TOC 

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.



 TOC 

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.



 TOC 

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.



 TOC 

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



 TOC 

7.  Security Considerations



 TOC 

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.



 TOC 

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.



 TOC 

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


 TOC 

9.  References



 TOC 

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 (TXT).
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[I-D.ietf-mmusic-ice] Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” draft-ietf-mmusic-ice-19 (work in progress), October 2007 (TXT).
[RFC3264] Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with Session Description Protocol (SDP),” RFC 3264, June 2002 (TXT).
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” RFC 4566, July 2006 (TXT).
[I-D.ietf-behave-rfc3489bis] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, “Session Traversal Utilities for (NAT) (STUN),” draft-ietf-behave-rfc3489bis-18 (work in progress), July 2008 (TXT).
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, “The Reason Header Field for the Session Initiation Protocol (SIP),” RFC 3326, December 2002 (TXT).


 TOC 

9.2. Informative References

[I-D.ietf-mmusic-ice-tcp] Perreault, S. and J. Rosenberg, “TCP Candidates with Interactive Connectivity Establishment (ICE),” draft-ietf-mmusic-ice-tcp-08 (work in progress), October 2009 (TXT).


 TOC 

Author's Address

  Jonathan Rosenberg
  Cisco
  Edison, NJ
  US
Phone:  +1 973 952-5000
Email:  jdrosen@cisco.com
URI:  http://www.jdrosen.net


 TOC 

Full Copyright Statement

Intellectual Property