SIPCORE Working Group C. Holmberg Internet-Draft Ericsson Intended status: Standards Track April 15, 2010 Expires: October 17, 2010 Indication of support for keep-alive draft-ietf-sipcore-keep-02.txt Abstract This specification defines a new Session Initiation Protocol (SIP) header field parameter, "keep", that SIP entities can use to negotiate explicit support of the NAT keep-alive mechanisms defined in the SIP Outbound specification. The parameter is defined for cases where the SIP Outbound mechanism is not supported, or in cases where it 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on October 17, 2010. Copyright Notice Copyright (c) 2010 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 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 Holmberg Expires October 17, 2010 [Page 1] Internet-Draft STUN-keep April 2010 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Use-case: Calls from non-registered UAs . . . . . . . . . 3 1.2. Use-case: SIP Outbound not supported . . . . . . . . . . . 3 1.3. Use-case: SIP dialog initiated Outbound flows . . . . . . 3 1.4. Use-case: Proxy-to-proxy heartbeat . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. User agent behavior . . . . . . . . . . . . . . . . . . . . . 4 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. User agent client behavior . . . . . . . . . . . . . . . . 5 4.2.1. Keep-alive negotiation for registration . . . . . . . 5 4.2.2. Keep-alive negotiation for dialog . . . . . . . . . . 5 4.3. User agent server behavior . . . . . . . . . . . . . . . . 6 4.3.1. Keep-alive negotiation for dialog . . . . . . . . . . 6 4.4. Keep-alive frequency . . . . . . . . . . . . . . . . . . . 6 5. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Edge proxy behavior . . . . . . . . . . . . . . . . . . . 7 5.2.1. Keep-alive negotiation for registration . . . . . . . 7 5.2.2. Keep-alive negotiation for dialog . . . . . . . . . . 7 5.3. Proxy behavior for proxy-to-proxy heartbeats . . . . . . . 7 5.3.1. Keep-alive negotiation for dialog . . . . . . . . . . 7 6. Overlap with connection reuse . . . . . . . . . . . . . . . . 8 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Example: Keep-alive negotiation for registration . . . . . 9 7.2. Example: Keep-alive negotiation for dialog from UA . . . . 10 7.3. Example: Keep-alive negotiation for dialog to UA . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9.1. IANA Registration of the SIP header field keep parameter . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Holmberg Expires October 17, 2010 [Page 2] Internet-Draft STUN-keep April 2010 1. Introduction Section 3.5 of SIP Outbound [RFC5626] defines two keep-alive mechanisms. Eventhough the keep-alive mechanisms are separated from the rest of the SIP Outbound mechanism, it is currently not possible to explicitly negotiate the usage of keep-alives, since the keep- alives are implicitly negotiated as part of the SIP Outbound negotation. However, there are also SIP Outbound use-cases where the keep-alives are not implicitly negotiated as part of the SIP Outbound negotiation, and therefor an explicit keep-alive negotiation mechanism is needed. In addition, there are use-cases where SIP Outbound is not supported, or where it cannot be applied, but where there is still a need to be able to negotiate the usage of keep- alives. This specification defines a new SIP header field parameter, "keep", that SIP entities can use to negotiate support of the NAT keep-alive mechanisms defined in the SIP Outbound specification [RFC5626]. The parameter is defined for cases where the SIP Outbound mechanism is not supported, or in cases where it cannot be applied. The usage of keep-alives can be negotiated as part of a registration, or as part of a dialog. The following sections describe use-cases where a mechanism to explicitly negotiate the usage of keep-alives is needed. 1.1. Use-case: Calls from non-registered UAs In some cases a UA does not register itself before making a call, but still needs to be able to make calls and send keep-alives in order to maintain NAT bindings open during the duration of the call. A typical example is emergency calls. 1.2. Use-case: SIP Outbound not supported There are cases where the SIP entities that need to be able to negotiate the usage of keep-alives do not support the SIP Outbound mechanism 1.3. Use-case: SIP dialog initiated Outbound flows SIP Outbound allows the establishment of flows using initial SIP dialog requests. As specified in [RFC5626], keep-alives are not implicitly negotiated for such flows, and therefor need to be separately negotiated. Holmberg Expires October 17, 2010 [Page 3] Internet-Draft STUN-keep April 2010 1.4. Use-case: Proxy-to-proxy heartbeat There are cases where SIP proxies need to perform heartbeats between themselves. Eventhough the heartbeats are normally not used for NAT traversal purpose, the keep-alive mechanisms defined in [RFC5626] can still be used to perform the heartbeats. 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]. 3. Definitions Edge proxy: As defined in [RFC5626], a SIP proxy that is located topologically between the registering User Agent (UA) and the Authoritative Proxy. Keep-alives: Refers to keep-alive messages using the mechanisms define defined in the SIP Outbound specification [RFC5626]. "keep" parameter: A SIP header field parameter that a SIP entity can insert to explicitly indicate that it supports the keep-alive mechanisms defined in the SIP Outbound specification [RFC5626]. The parameter is defined for the SIP Contact, Path and Record-Route header fields. 4. User agent behavior 4.1. General This section describes how a UA (User Agent) negotiates the usage of keep-alives between itself and its edge proxy, for a registration or a dialog. A UA will only send keep-alives towards its edge proxy, and MUST NOT expect to receive edge proxy initiated keep-alives. A UA that supports keep-alives MUST insert a "keep" parameter in its Contact header field even if it also indicates support of SIP Outbound [RFC5626], in order to be able to negotiate the usage of keep-alives also in cases where the edge proxy only supports keep- alives, but not the other parts of SIP Outbound. Holmberg Expires October 17, 2010 [Page 4] Internet-Draft STUN-keep April 2010 As defined in [RFC5626], a UA that supports keep-alives MUST act as a Session Traversal Utilities for NAT (STUN) client [RFC5389]. The UA MUST support the amount of STUN which is required to apply the STUN keep-alive mechanism defined in [RFC5626], and the UA MUST support the CRLF keep-alive mechanism defined in [RFC5626]. In addition, as defined in [RFC5389], the UAC MUST be able to process the SIP Path header [RFC3327], in order to detect whether the edge proxy supports keep-alives. NOTE: Keep-alives needs to be negotiated when a registration or dialog is initiated. It is not possible to negotiate/re-negotiate the usage keep-alives later during the registration or dialog, and the usage of the "keep" parameter in re-registration requests and dialog modification requsts is not specified. NOTE: Since there are UAs 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 an edge proxy has not indicated support of keep-alives using the "keep" parameter. However, the "keep" parameter is still important in order for the UA to inform the edge proxy that the UA 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. 4.2. User agent client behavior 4.2.1. Keep-alive negotiation for registration When a UAC sends a REGISTER request for a new registration, if the UAC is willing to send keep-alives associated with the registration, it MUST insert a "keep" parameter in its Contact header field of the REGISTER request. When the UAC receives the REGISTER response, if the top-most Path header field (edge proxy) of the response contains a "keep" parameter, the UAC MUST start to send keep-alives towards the edge proxy, and it MUST send keep-alives for the remaining duration of the registration. When the registration is terminated, the UAC MUST cease the sending of keep-alives negotiated for the registration. 4.2.2. Keep-alive negotiation for dialog When a UAC sends an initial request (e.g. a SIP INVITE request) for a dialog, if the UAC is willing to send keep-alives associated with the dialog, it MUST insert a "keep" parameter in its Contact header field of the request. Holmberg Expires October 17, 2010 [Page 5] Internet-Draft STUN-keep April 2010 When the UAC receives the response(s) to the initial request for the dialog, if the top-most Record-Route header field (edge proxy) of response(s) contains a "keep" parameter, the UAC MUST start to send keep-alives towards the edge proxy for the remaining duration of the dialog. When the dialog is terminated, the UAC MUST cease the sending of keep-alives negotiated for the dialog. 4.3. User agent server behavior 4.3.1. Keep-alive negotiation for dialog When a UAS receives an initial request for a dialog, if the top-most Record-Route header filed contains a "keep" parameter, and if the UAS is willing to send keep-alives associated with the dialog, it MUST insert a "keep" parameter in its Contact header field in the response(s) to the request. After that the UAS MUST start to send keep-alives towards the edge proxy, and it MUST send keep-alives for the remaining duration of the registration. 4.4. Keep-alive frequency If the SIP message that contains the "keep" parameter of the edge proxy also contains a Flow-Timer header field [RFC5626], it is strongly RECOMMENDED that the UA uses the server recommended keep- alive frequency value, provided in the header field, and sends keep- alives so that the interval between each keep-alive is randomly distributed between 80% and 100% of the provided value. If the UA does not receive a Flow-Timer header field from the edge proxy, it can send keep-alives at its discretion. 5. Proxy behavior 5.1. General A proxy that supports the mechanism specified in this specification MUST act as a STUN server [RFC5389], and MUST support the amount of STUN which is required to apply the STUN keep-alive technique [RFC5626]. The edge proxy MUST also process double-CRLF keep-alives, as defined in [RFC5626]. If a proxy also generates keep-alives (see proxy-to-proxy case), it MUST also act as a STUN client [RFC5389]. Holmberg Expires October 17, 2010 [Page 6] Internet-Draft STUN-keep April 2010 5.2. Edge proxy behavior 5.2.1. Keep-alive negotiation for registration When an edge proxy receives an initial REGISTER request for a registration from a UA behind the edge proxy, the Contact header field of the request contains a "keep" parameter, and if the edge proxy is willing to receive keep-alives from the UA for the associated registration, the edge proxy MUST insert a "keep" parameter in its Path header field of the associated REGISTER response. In addition, the edge proxy MAY insert a Flow-Timer header field [RFC5626], which indicates the recommended keep-alive frequency for the registration. 5.2.2. Keep-alive negotiation for dialog When an edge proxy receives a dialog initiation request from a UAC behind the edge proxy, the Contact header field of the request contains a "keep" parameter, and if the edge proxy is willing to receive keep-alives from the UA for the associated dialog, the edge proxy MUST insert a "keep" parameter in its Record-Route header field of the associated response(s). In addition, the edge proxy MAY insert a Flow-Timer header field [RFC5626], which indicates the recommended keep-alive frequency for the dialog. When an edge proxy receives an inbound dialog initiation request towards a UAS behind the edge proxy, and if the edge proxy is willing to receive keep-alives from the UA for the associated dialog, the edge proxy MUST insert a "keep" parameter in its Record-Route header field of the request. In addition, the edge proxy MAY insert a Flow- Timer header field [RFC5626], which indicates the recommended keep- alive frequency for the dialog. When the edge proxy receives response(s) associated with the request from the UAS, associated with the request, if the Contact header field of the response(s) contains a "keep" parameter, the edge proxy can assume that the UAS will send keep-alives associated with the dialog. 5.3. Proxy behavior for proxy-to-proxy heartbeats 5.3.1. Keep-alive negotiation for dialog When a proxy receives a dialog initiation request from its previous- hop proxy, and the top-most Record-Route header field of the request contains a "keep" parameter, if the proxy is willing to send and receive keep-alives from the previous-hop proxy for the associated dialog, the proxy MUST insert a "keep" parameter in its Record-Route header field of the associated response(s) sent towards the previous- hop proxy. After that the proxy MUST send keep-alives, and accept Holmberg Expires October 17, 2010 [Page 7] Internet-Draft STUN-keep April 2010 keep-alives sent from the previous-hop proxy, for the duration of the dialog. When a proxy forwards a dialog initiation request towards its next- hop proxy, and it wants to negotiate the usage of keep-alives with that next-hop proxy, it MUST include a "keep" parameter in its Record-Record header field of the request. When the proxy receives the associated response(s), if the Record-Route header field that represents the next-hop proxy contains a "keep" parameter, the proxy MUST start sending keep-alives towards the next-hop proxy for the duration of the dialog. NOTE: The usage of the Flow-Timer header field for proxy-to-proxy heartbeats is unspecified. OPEN ISSUE: It still needs to be discuss whether it should be possible to negotiate that the sending of keep-alives between proxies continue after the dialog, for which the keep-alives were negotiated, has been terminated. 6. 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 [I-D.ietf-sip-connect-reuse] as well as the "keep" header field parameter defined in this specification. 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. 7. Examples Holmberg Expires October 17, 2010 [Page 8] Internet-Draft STUN-keep April 2010 7.1. Example: Keep-alive negotiation for registration The figure shows an example where the UAC sends a REGISTER request. The UAC inserts a "keep" parameter in its Contact header field, to indicate that it is willing to send keep-alives during the liftime of the registration. The edge proxy (P1) supports the receiving of keep-alives, so it inserts a "keep" parameter in its Path header field of the REGISTER response that it forwards towards the UAC. In addition, the edge proxy inserts a Flow-Timer header field in the response. The header field value indicates the server recommended keep-alive frequency. When the UAC receives the REGISTER response, and detects that the edge proxy supports the receiving of keep-alives, it starts to send periodic keep-alives (in this example using the STUN keep-alive technique) UAC P1 (Edge Proxy) REGISTRAR | | | |--- REGISTER------------->| | | Contact: UAC;keep | | | |--- REGISTER-------------->| | | Path: P1 | | | Contact: UAC;keep | | | | | |<-- 200 OK ----------------| | | Path: P1 | | | Contact: UAC;keep | |<-- 200 OK ---------------| | | Path: P1;keep | | | Contact: UAC;keep | | | Flow-Timer: 30 | | | | | | | | | *** Timeout *** | | | | |=== STUN request ========>| | |<== STUN response ========| | | | | | *** Timeout *** | | | | |=== STUN request ========>| | |<== STUN response ========| | | | | Holmberg Expires October 17, 2010 [Page 9] Internet-Draft STUN-keep April 2010 Figure 1: Example call flow 7.2. Example: Keep-alive negotiation for dialog from UA The figure shows an example where the UAC sends an INVITE request. The UAC inserts a "keep" parameter in its Contact header field, to indicate that it is willing to send keep-alives during the lifetime of the dialog. The edge proxy (P1) supports the receiving of keep-alives, so it inserts a "keep" parameter in its Record-Route header field of the INVITE response that it forwards towards the UAC. In addition, the edge proxy inserts a Flow-Timer header field in the response. The header field value indicates the server recommended keep-alive frequency. When the UAC receives the INVITE response, and detects that the edge proxy supports the receiving of keep-alives, it starts to send periodic keep-alives (in this example using the STUN keep-alive technique) Holmberg Expires October 17, 2010 [Page 10] Internet-Draft STUN-keep April 2010 UAC P1 (Edge Proxy) Remote SIP network | | | |--- INVITE -------------->| | | Contact: UAC;keep | | | |--- INVITE --------------->| | | Record-Route: P1 | | | Contact: UAC;keep | | | | | | | | | | | |<-- 200 OK ----------------| | | Record-Route: P1 | | | Contact: UAS | |<-- 200 OK ---------------| | | Record-Route: P1;keep | | | Contact: UAS | | | Flow-Timer: 30 | | | | | |--- ACK ----------------->| | | | | | |--- ACK ------------------>| | | | | *** Timeout *** | | | | |=== STUN request ========>| | |<== STUN response ========| | | | | | *** Timeout *** | | | | |=== STUN request ========>| | |<== STUN response ========| | | | | | | | |--- BYE ----------------->| | | | | | |--- BYE ------------------>| | | | | |<-- 200 OK ----------------| | | | Figure 2: Example call flow 7.3. Example: Keep-alive negotiation for dialog to UA The figure shows an example where P1 (edge proxy) forwards an INVITE request towards the UAS. P1 inserts a "keep" parameter in its Record-Route header field, to indicate that it is willing to receive keep-alives during the lifetime of the dialog. In addition, the edge Holmberg Expires October 17, 2010 [Page 11] Internet-Draft STUN-keep April 2010 proxy inserts a Flow-Timer header field in the response. The header field value indicates the server recommended keep-alive frequency. The UAS is willing to send keep-alives, so it inserts a "keep" parameter in its Contact header field of the INVITE 200 (OK) response. In addition, the edge proxy inserts a Flow-Timer header field in the response. The header field value indicates the server recommended keep-alive frequency. After that the UAS starts to send periodic keep-alives (in this example using the STUN keep-alive technique) Holmberg Expires October 17, 2010 [Page 12] Internet-Draft STUN-keep April 2010 Remote SIP network P1 (Edge Proxy) UAS | | | |--- INVITE -------------->| | | Contact: UAC | | | |--- INVITE --------------->| | | Record-Route: P1;keep | | | Contact: UAC | | | Flow-Timer: 30 | | | | | | | | | | | |<-- 200 OK ----------------| | | Record-Route: P1;keep | | | Contact: UAS;keep | |<-- 200 OK ---------------| | | Record-Route: P1;keep | | | Contact: UAS;keep | | | | | |--- ACK ----------------->| | | | | | |--- ACK ------------------>| | | | | *** Timeout *** | | | | | |<== STUN request ==========| | |=== STUN response ========>| | | | | *** Timeout *** | | | | | |<== STUN request ==========| | |=== STUN response ========>| | | | |--- BYE ----------------->| | | | | | |--- BYE ------------------>| | | | | |<-- 200 OK ----------------| | | | Figure 3: Example call flow 8. Security Considerations Holmberg Expires October 17, 2010 [Page 13] Internet-Draft STUN-keep April 2010 9. IANA Considerations 9.1. IANA Registration of the SIP header field keep parameter 10. Acknowledgements Thanks to Staffan Blau, Francois Audet, Hadriel Kaplan, Sean Schneyer, Milo Orsic, John Elwell and Ya-Ching Tan 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. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009. 11.2. Informative References [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 October 17, 2010 [Page 14] Internet-Draft STUN-keep April 2010 Author's Address Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Holmberg Expires October 17, 2010 [Page 15]