Network Working Group F. Miller Internet-Draft Cornfed Systems, LLC Expires: August 5, 2006 February 2006 The SIP PING Method draft-fwmiller-ping-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 5, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The Session Initiation Protocol (SIP) has the potential for long periods of time to elapse when no signaling traffic is sent between a User Agent Client (UAC) and a User Agent Server (UAS). There are situations when it is advantageous to have some signaling traffic flow periodically between these endpoints or to have a quick, lightweight check whether a UAS is alive. The PING method is proposed that can be used for these purposes. Miller Expires August 5, 2006 [Page 1] Internet-Draft ping February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. PING Method . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Header Field Support for PING Method . . . . . . . . . . . 4 2.2. Response to the PING Method . . . . . . . . . . . . . . . 6 2.3. Message Body Inclusion . . . . . . . . . . . . . . . . . . 6 2.4. User Agent Behavior . . . . . . . . . . . . . . . . . . . 6 2.5. Behavior of SIP Proxy and Redirect Servers . . . . . . . . 7 2.5.1. Proxy Server . . . . . . . . . . . . . . . . . . . . . 7 2.5.2. Forking Proxy Server . . . . . . . . . . . . . . . . . 7 2.5.3. Redirection Server . . . . . . . . . . . . . . . . . . 7 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Miller Expires August 5, 2006 [Page 2] Internet-Draft ping February 2006 1. Introduction Two SIP entities pass signaling traffic between them as required to support SIP-based services. There can be long periods of time either when session is established or when no session exists when no traffic is flowing between the endpoints. There are situations where some signaling traffic should be sent between the UAC and UAS. For example, if one of the endpoints is behind a Network Address Translation (NAT), signaling traffic may be needed to keep the NAT port bindings alive. The PING method is intended to confirm that the endpoints are alive and verify that a signaling path is still valid. Miller Expires August 5, 2006 [Page 3] Internet-Draft ping February 2006 2. PING Method The PING method is used to determine if a UAS is alive and to validate a signaling path. The PING method is not used to change the state of SIP calls, nor does it change the state of sessions initiated by SIP. Rather, it provides an indication to both ends of a session that signaling messages can still flow between them. A PING request may be sent at any time. PINGs may be sent periodically to serve as a heartbeat. A UAC MUST NOT have more than one outstanding PING transaction in existence at any time with a specific UAS. The only interval specified in this standard is that subsequent PING requests MUST be sent with at least a minimum of 500 milliseconds between them. A PING request is routed the same way any other request is routed. This can be either direct signaling between the UAC and UAS or a signaling path involving SIP servers that potentially add themselves to the Record-Route headers. PING requests are sent unreliably. This means that a UAC sends a single PING request to an UAS, and waits for a response. If no response arrives before the expiration interval, the transaction is terminated and the UAC is notified that not response was received. It is up to the UAC to decide whether another PING is sent. If it is, the new PING request represents a new PING transaction. 2.1. Header Field Support for PING Method The PING request does not carry any information other than the intent to check for the liveness of the UAS and the signaling path validity. As such, only a few headers are used in both the PING request and its associated response. Header Where PING ------ ----- ---- Accept - - Accept-Encoding - - Accept-Language - - Alert-Info - - Allow - - Authentication-Info - - Authorization - - Call-ID R m Call-ID 200 m Call-Info - - Miller Expires August 5, 2006 [Page 4] Internet-Draft ping February 2006 Contact - - Content-Disposition - - Content-Encoding - - Content-Language - - Content-Length R t Content-Type - - CSeq R m CSeq 200 m Date - - Error-Info - - Expires - - From R m From 200 m In-Reply-To - - Max-Forwards R m Max-Forwards 200 m Min-Expires - - MIME-Version - - Organization - - Priority - - Proxy-Authenticate - - Proxy-Authorization - - Proxy-Require - - Record-Route R o Record-Route 200 o Reply-To - - Require - - Retry-After - - Route R c Route 200 c Server - - Subject - - Supported - - Timestamp - - To R m To 200 m Unsupported - - User-Agent R o User-Agent 200 o Via R m Via 200 m Warning - - WWW-Authenticate - - If a Content-Length field is included in the PING request, it MUST be set to zero (0). The intent is to provide as simple a message as possible to allow for Miller Expires August 5, 2006 [Page 5] Internet-Draft ping February 2006 implementations (particularly for servers) to optimize PING message processing. 2.2. Response to the PING Method A UAC formats a PING request as desired and sends it to the UAS. The request is sent using the same routing rules by which an OPTIONS non- INVITE transaction would be sent. The request is sent unreliably, i.e. it is not retransmitted. The UAC waits 5 seconds for a response. If a response is received or the UAC times out waiting for a response, the PING transaction is considered terminated and the UAC is notified of the outcome. UAC UAS | | | PING | |--------->| | | | 200 OK | |<---------| | | There is only one defined response to a PING messages. This means that a UAS that receives, recognizes, and supports the PING method MUST only send one possible response back to the UAC. The defined response is a 200 OK response. A UAS that supports reception of the PING method MUST respond immediately with a 200 OK message when it receives a PING request. If a UAS that does not support the PING method receives a PING request, it will generate other responses, e.g. a 501 Not Implemented per [1]. A UAC SHOULD accept any response other than a 1xx provisional response or a 3xx redirection. If a response other than a 1xx or a 3xx is received, the UAC SHOULD assume that the UAS does not recognize or support the PING method but the UAC SHOULD accept the response as if it were a 200 OK response. A UAC receiving a 1xx or 3xx response SHOULD drop the response as if it were never received. 2.3. Message Body Inclusion A PING request MUST NOT contain a message body. 2.4. User Agent Behavior Unless otherwise stated, the protocol rules for the PING request governing the usage of tags, Route, and Record-Route, retransmission Miller Expires August 5, 2006 [Page 6] Internet-Draft ping February 2006 and reliability, CSeq incrementing and message formatting follow those in [1] as defined for the OPTIONS request. A PING request MAY NOT be canceled. 2.5. Behavior of SIP Proxy and Redirect Servers 2.5.1. Proxy Server Unless stated otherwise, the protocol rules for the PING request at a proxy are identical to those for a OPTIONS request as specified in [1]. 2.5.2. Forking Proxy Server Unless stated otherwise, the protocol rules for the PING request at a proxy are identical to those for a OPTIONS request as specified in [1]. 2.5.3. Redirection Server Unless stated otherwise, the protocol rules for the PING request at a proxy are identical to those for a OPTIONS request as specified in [1]. Miller Expires August 5, 2006 [Page 7] Internet-Draft ping February 2006 3. Security Considerations The only security consideration is that of a Denial of Service (DoS). A "PING Storm" DoS attack can be launched at a UAS if PING requests are sent at closer intervals than 500 milliseconds. Even 500 milliseconds can be considered tight. It is RECOMMENDED that PING request intervals be at least several seconds if possible. 4. References [1] 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. Miller Expires August 5, 2006 [Page 8] Internet-Draft ping February 2006 Author's Address Frank W. Miller Cornfed Systems, LLC 103 Overhill Road Baltimore, MD 21210 US Phone: +1 410 404 8790 Email: fwmiller@cornfed.com URI: http://www.cornfed.com/ Miller Expires August 5, 2006 [Page 9] Internet-Draft ping February 2006 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 (2006). 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. Miller Expires August 5, 2006 [Page 10]