Network Working Group F. Miller Internet-Draft Cornfed Systems, LLC Expires: August 22, 2006 February 18, 2006 The SIP PING Method draft-fwmiller-ping-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 August 22, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The SIP protocol has the potential for long periods of time to elapse when no signaling traffic is sent between a UAC and a UAS. There are situations when it is advantageous to have some signaling traffic flow periodically between these endpoints. A PING method is proposed that can be used for this purpose. Miller Expires August 22, 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 . . . . . . . . 6 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 22, 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 periodic signaling traffic should be sent. 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 only to alert an endpoint that a signaling path is valid. Miller Expires August 22, 2006 [Page 3] Internet-Draft ping February 2006 2. PING Method The PING method is used 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. It is likely that an implementation will want to send a PING 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. The signaling path for the PING method is the signaling path established as the result of a call setup. This can be either direct signaling between the calling and called User Agents or a signaling path involving SIP proxy servers that were involved in the call setup and added themselves to the Record-Route header on the initial INVITE message. 2.1. Header Field Support for PING Method The PING request does not carry any information other than the intent to check for signaling path validity. As such, only a few headers are used in both the PING request and its associated 200 OK 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 - - Contact - - Content-Disposition - - Content-Encoding - - Content-Language - - Content-Length R t Content-Type - - Miller Expires August 22, 2006 [Page 4] Internet-Draft ping February 2006 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 implementations (particularly for servers) to optimize PING message processing. Miller Expires August 22, 2006 [Page 5] Internet-Draft ping February 2006 2.2. Response to the PING Method When a UAC wants to check the validity of a session, it formats a PING request and send it to the UAS. The request is sent using the same rules by which a BYE non-INVITE transaction would be sent. UAC UAS | | | PING | |--------->| | | | 200 OK | |<---------| | | There are only two defined responses to a PING messages. By defined, we mean that these are the only responses that a UAC that sends the PING request should recognize as correctly validating the signaling path. The first valid 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 a 405 Method Not Allowed response per [1]. This response is the second defined response. If a UAC receives a 405 from a UAS, it should interpret that response as if it were a 200 OK that was received from an UAS that supports the PING method. Allowing this response to be received allows PING to be used with older implementations that do not support the PING method. 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 and reliability, CSeq incrementing and message formatting follow those in [1] as defined for the BYE request. A PING request MAY NOT be canceled. 2.5. Behavior of SIP Proxy and Redirect Servers Miller Expires August 22, 2006 [Page 6] Internet-Draft ping February 2006 2.5.1. Proxy Server Unless stated otherwise, the protocol rules for the PING request at a proxy are identical to those for a BYE 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 BYE 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 BYE request as specified in [1]. Miller Expires August 22, 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 22, 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 22, 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 22, 2006 [Page 10]