SIPCORE Working Group C. Holmberg Internet-Draft Ericsson Intended status: Informational December 1, 2009 Expires: June 4, 2010 Indication of support for keep-alive draft-ietf-sipcore-keep-01.txt Abstract This specification defines a new SIP Via header parameter, "keep" which SIP entities can use to indicate support of the NAT keep-alive techniques defined in SIP Outbound, in cases where the Outbound procedures are not supported or cannot be applied. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 June 4, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Holmberg Expires June 4, 2010 [Page 1] Internet-Draft STUN-keep December 2009 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Client behavior . . . . . . . . . . . . . . . . . . . . . . . 4 6. Server behavior . . . . . . . . . . . . . . . . . . . . . . . 5 7. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Overlap with connection reuse . . . . . . . . . . . . . . . . 6 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Example with keep-alive negotiation during registration . 7 9.2. Example with keep-alive negotiation during session establishment . . . . . . . . . . . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 11.1. IANA Registration of the SIP Via keep parameter . . . . . 10 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 13.1. Normative References . . . . . . . . . . . . . . . . . . . 10 13.2. Informative References . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Holmberg Expires June 4, 2010 [Page 2] Internet-Draft STUN-keep December 2009 1. Introduction Chapter 3.5 of [I-D.ietf-sip-outbound] defines two keep-alive techniques. Even though the keep-alive techniques are separated from the Outbound mechanism [I-D.ietf-sip-outbound], it is currently not possible to indicate support of the keep-alive techniques without also indicating support for the Outbound mechanism. In addition, as described in [I-D.ietf-sip-outbound], for dialog initiated outbound flows a separate mechanism is used to indicate and negotiate support of keep-alives. The Outbound mechanism is enabled during the UA registration phase. However, there are use-cases where the UA does not register itself, but still needs to be able to make calls and maintain NAT bindings open during the duration of that call. A typical example is emergency calls. There are also cases where entities do not support the Outbound mechanism, but still want to be able to indicate support and use the keep-alive techniques defined in [I-D.ietf-sip-outbound]. In addition, the Outbound mechanism also allows the establishment of flows using initial dialog SIP requests. As specified in [I-D.ietf-sip-outbound], keep-alives must be separately negotiated for such flows. Another use-case is when network entities (SIP proxies) need to perform heartbeats between themselves. The keep-alive techniqurs defined in [I-D.ietf-sip-outbound] can be used for providing the heartbeats, and the mechanism in this document can be used by the entities to indicate and negotiate support of the keep-alive techniques. This specification defines a new SIP Via header parameter, "keep", which can be used by a UA to indicate support of the keep-alive techniques defined in [I-D.ietf-sip-outbound]. The UA will insert the "keep" parameter in the Via header of the REGISTER request, or the initial session request if not registered. This specification also defines a "yes" value for the "keep" parameter. The edge proxy will add a "yes" value to the "keep" parameter, if received in the topmost Via header, to indicate support of the keep-alive techniques defined in [I-D.ietf-sip-outbound]. 2. Conventions 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 BCP 14, RFC 2119 [RFC2119]. Holmberg Expires June 4, 2010 [Page 3] Internet-Draft STUN-keep December 2009 3. Definitions Edge proxy: As defined in [I-D.ietf-sip-outbound], an Edge Proxy is any proxy that is located topologically between the registering User Agent and the Authoritative Proxy. The "first" edge proxy refers to the first edge proxy encountered when a UA sends a request. 'keep' Parameter: The 'keep' parameter is a SIP Via header parameter which indicates that the entity inserting the parameter supports the keep-alive techniques defined in [I-D.ietf-sip-outbound]. The parameter may carry an associated parameter value. 4. Requirements REQ 1: It MUST be possible for a SIP entity acting as a UAC to indicate, during registration and session establishment, support of the keep-alive techniques defined in [I-D.ietf-sip-outbound] towards the next hop, if only the keep-alive part of [I-D.ietf-sip-outbound] is used for the registration or session REQ 2: It MUST be possible for a SIP entity acting as a UAS to indicate, during registration and session establishment, support of the keep-alive techniques defined in [I-D.ietf-sip-outbound] towards the previous hop, if only the keep-alive part of [I-D.ietf-sip-outbound] is used for the registration or session 5. Client behavior A SIP entity aciting as a UAC which supports the method defined in this specification MUST act as a STUN client [I-D.ietf-behave-rfc3489bis], and MUST support the amount of STUN which is required to apply the STUN keep-alive technique [I-D.ietf-sip-outbound]. When a SIP entity acting as a UAC (UA or proxy) which supports the method defined in this specification sends a SIP REGISTER request, and the UAC wants to send keep-alives towards the next hop, the entity MUST insert a "keep" Via parameter in the SIP request. If the Via header in the SIP REGISTER response contains a "keep" parameter with a "yes" value, the UA knows that the keep-alive techniques defined in [I-D.ietf-sip-outbound] can be used between the entity and the next hop during the duration of the registration. If the SIP REGISTER response contains a Flow-Timer header [I-D.ietf-sip-outbound], and the UAC uses the server recommended keepalive frequency provided in the header, the UAC SHOULD send its keepalives so that the interval between each keepalive is randomly Holmberg Expires June 4, 2010 [Page 4] Internet-Draft STUN-keep December 2009 distributed between 80% and 100% of the server provided time. If no Flow-Timer header field was present in the SIP REGISTER response, the UA can send keepalives at its discretion. The UA must insert a "keep" parameter even if the UA also indicates support of Outbound [I-D.ietf-sip-outbound], to allow keep-alive usage in cases where the edge proxy will only support "keep". When a UAC which supports the method defined in this specification sends an initial SIP request, the UAC has not registered itself via the edge proxy towards which the SIP request is sent, and the UAC wants to send keep-alives towards the next hop, the UAC MUST include a "keep" Via parameter in the SIP request. If the Via header header in the initial SIP responses contains a "keep" parameter with a "yes" value, the UA knows that the keep-alive techniques defined in [I-D.ietf-sip-outbound] can be used between the UAC and the next hop during the duration of the call. If the initial SIP response contains a Flow-Timer header [I-D.ietf-sip-outbound], and the UAC uses the recommended keepalive frequency provided in the header, the UAC SHOULD send its keepalives so that the interval between each keepalive is randomly distributed between 80% and 100% of the server provided time. If no Flow-Timer header field was present in the initial SIP response, the UA can send keepalives at its discretion. If the UAC wishes to apply keep-alive for future calls, it MUST insert a "keep" Via parameter in the initial SIP request of those calls. NOTE: Since there are clients that already use CRLF keep-alives, and proxies are expected to be able to receive it, this specification does not forbid the sending of CRLF keep-alives even when no "keep=yes" indication has been received from the edge proxy. However, the indicator is still important in order for the client to inform the edge proxy that the client supports CRLF keep-alives, so that the edge proxy does not use other mechanisms (e.g. short registration refresh intervals) in order to make sure the NAT bindings are kept open. 6. Server behavior A SIP entity acting as a UAS (UA or proxy) which supports the method defined in this specification MUST act as a STUN server [I-D.ietf-behave-rfc3489bis], and MUST support the amount of STUN which is required to apply the STUN keep-alive technique [I-D.ietf-sip-outbound]. The UAS MUST also process double-CRLF keep- alives, as defined in [I-D.ietf-sip-outbound]. When a UAS that supports the method defined in this specification recieves a SIP REGISTER request which contains a "keep" parameter in Holmberg Expires June 4, 2010 [Page 5] Internet-Draft STUN-keep December 2009 the topmost Via header, and the UAS wants to allow the sender of the SIP REGISTER request to send keep-alives towards the UAS during the duration of the registration, the UAS proxy MUST add a "yes" value to the "keep" parameter. In addition the UAS MAY include a Flow-Timer header field if the associated SIP REGISTER response. When a UAS that supports the method defined in this specification recieves an initial SIP request which contains a "keep" parameter in the topmost Via header, and the UAS wants to allow the sender of the initial SIP request to send keep-alives towards the UAS during the duration of the call, the UAS proxy MUST add a "yes" value to the "keep" parameter. In addition the UAS MAY include a Flow-Timer header field if the associated initial SIP response. 7. Proxy behavior A proxy acting as a UAC, that wants to use the mechanism in this document, shall follow the procedures defined in Section 5. A proxy acting as a UAS, that wants to use the mechanism in this document, shall follow the procedures defined in Section 6. 8. Overlap with connection reuse The connect-reuse specification [I-D.ietf-sip-connect-reuse] specifies how to use connection-oriented transports to send requests in the reverse direction. SIP entity A opens a connection to entity B in order to send a request. Under certain conditions entity B can reuse that connection for sending requests in the backwards direction to A as well. However, the connect-reuse specification does not define a keep-alive mechanism for this connection. The technique specified in this draft is thus orthogonal to the purpose of connection reuse. An entity that wants to use connection- reuse as well as indicate keep-alive mechanism on that connection will insert both the "alias" parameter defined in [connect-reuse] as well as the "keep" parameter defined in this memo. Inserting only one of these parameters is not a substitute for the other. Thus, while the presence of a "keep" parameter will indicate that the enity supports keep-alives in order to keep the connection open, no inference can be drawn on whether that connection can be used for requests in the backwards direction. Holmberg Expires June 4, 2010 [Page 6] Internet-Draft STUN-keep December 2009 9. Examples 9.1. Example with keep-alive negotiation during registration The figure shows an example where a UAC sends an REGISTER request, in which it indicates support of keep-alive by inserting a "keep" parameter in the Via header of the REGISTER request. The edge proxy (P1) also supports the keep-alive mechanism, so it adds a "yes" value to the "keep" parameter to the Via header of the UAC. The request is then fowarded towards the registrar. When the UAC receives the 200 OK (REGISTER) response from the registrar it finds out that the edge proxy supports keep-alive. After that the UAC sends periodic keep- alives (in this example using the STUN keep-alive technique) during the duration of the registration. The edge proxy (P1) has inserted a Flow-Timer header in the 200 OK (REGISTER) response, indicating a recommented keep-alive interval of 30 seconds. UAC P1 REGISTRAR | | | |--- REGISTER------------->| | | Via: UAC;keep | | | |--- REGISTER-------------->| | | Via: UAC;keep=yes | | | Via: P1 | | | | | |<-- 200 OK ----------------| | | Via: UAC;keep=yes | | | Via: P1 | |<-- 200 OK ---------------| | | Via: UAC;keep=yes | | | Flow-Timer: 30 | | | | | | | | | *** Timeout *** | | | | |=== STUN request ========>| | |<== STUN response ========| | | | | | *** Timeout *** | | | | |=== STUN request ========>| | |<== STUN response ========| | | | | Figure 1: Example call flow Holmberg Expires June 4, 2010 [Page 7] Internet-Draft STUN-keep December 2009 9.2. Example with keep-alive negotiation during session establishment The figure shows an example where a non-registered UAC sends an INVITE request, in which it indicates support of keep-alive by inserting a "keep" parameter in the Via header of the INVITE request. The edge proxy (P1) also supports the keep-alive mechanism, so it adds a "yes" value to the "keep" parameter to the Via header of the UAC. The request is then fowarded towards the UAS. When the UAC receives the 200 OK (INVITE) response from the UAS it finds out that the edge proxy supports keep-alive. After that the UAC sends periodic keep-alives (in this example using the STUN keep-alive technique) during the duration of the call. The edge proxy (P1) has inserted a Flow-Timer header in the 200 OK (INVITE) response, indicating a recommented keep-alive interval of 30 seconds. Holmberg Expires June 4, 2010 [Page 8] Internet-Draft STUN-keep December 2009 UAC P1 UAS | | | |--- INVITE -------------->| | | Via: UAC;keep | | | |--- INVITE --------------->| | | Via: UAC;keep=yes | | | Via: P1 | | | | | |<-- 200 OK ----------------| | | Via: UAC;keep=yes | | | Via: P1 | |<-- 200 OK ---------------| | | Via: UAC;keep=yes | | | Flow-Timer: 30 | | | | | |--- ACK ----------------->| | | | | | |--- ACK ------------------>| | | | | *** Timeout *** | | | | |=== STUN request ========>| | |<== STUN response ========| | | | | | *** Timeout *** | | | | |=== STUN request ========>| | |<== STUN response ========| | | | | | | | |--- BYE ----------------->| | | | | | |--- BYE ------------------>| | | | | |<-- 200 OK ----------------| | | | Figure 2: Example call flow 10. Security Considerations 11. IANA Considerations Holmberg Expires June 4, 2010 [Page 9] Internet-Draft STUN-keep December 2009 11.1. IANA Registration of the SIP Via keep parameter 12. Acknowledgements Thanks to Staffan Blau, Francois Audet, Hadriel Kaplan, Sean Schneyer and Milo Orsic for their comments on the initial draft. Thanks to Juha Heinaenen, Jiri Kuthan and Dean Willis for their comments on the list. Thanks to Vijay Gurbani for providing text about the relationship with the connect-reuse specification. 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. 13.2. Informative References [I-D.ietf-sip-outbound] Jennings, C., "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", draft-ietf-sip-outbound-20 (work in progress), June 2009. [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. [I-D.ietf-sip-connect-reuse] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in the Session Initiation Protocol (SIP)", draft-ietf-sip-connect-reuse-14 (work in progress), August 2009. Holmberg Expires June 4, 2010 [Page 10] Internet-Draft STUN-keep December 2009 Author's Address Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Holmberg Expires June 4, 2010 [Page 11]