RFC 6223
Indication of Support for Keep-Alive
RFC 6223: Indication of Support for Keep-Alive 🎀
Okay bestie, this one is RFC 6223, titled Indication of Support for Keep-Alive 💖 It's an IETF document from April 2011, written by C. Holmberg at Ericsson 🧚 It's on the Standards Track, which means it's a real Internet standard, not just a suggestion. Its ISSN is 2070-1721. The header doesn't list any RFCs it obsoletes or updates, so it's a fresh one 🌸
Abstract ✨
This spec adds a brand new Session Initiation Protocol (SIP) Via header field parameter called "keep" 🦋 It lets neighbouring SIP entities explicitly negotiate whether they'll use the NAT keep-alive mechanisms from SIP Outbound. That's useful when SIP Outbound isn't supported, can't be applied, or doesn't implicitly negotiate keep-alives as part of its own negotiation 💅
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6223.
Copyright Notice
Copyright (c) 2011 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 described in the Simplified BSD License.
Table of Contents 🍓
1. Introduction ....................................................2
1.1. Use-Case: Dialog from Non-Registered UAs ...................3
1.2. Use-Case: SIP Outbound Not Supported .......................3
1.3. Use-Case: SIP Dialog Initiated Outbound Flows ..............3
2. Conventions .....................................................3
3. Definitions .....................................................4
4. User Agent and Proxy Behavior ...................................4
4.1. General ....................................................4
4.2. Lifetime of Keep-Alives ....................................5
4.2.1. General .............................................5
4.2.2. Keep-Alives Associated with Registration ............5
4.2.3. Keep-Alives Associated with Dialog ..................6
4.3. Behavior of a SIP Entity Willing to Send Keep-Alives .......6
4.4. Behavior of a SIP Entity Willing to Receive Keep-Alives ....7
5. Keep-Alive Frequency ............................................8
6. Connection Reuse ................................................9
7. Examples ........................................................9
7.1. General ....................................................9
7.2. Keep-Alive Negotiation Associated with
Registration: UA-Proxy .....................................9
7.3. Keep-Alive Negotiation Associated with Dialog: UA-Proxy ...11
7.4. Keep-Alive Negotiation Associated with Dialog: UA-UA ......13
8. Grammar ........................................................15
8.1. General ...................................................15
8.2. ABNF ......................................................15
9. IANA Considerations ............................................15
9.1. "keep" Via Header Field Parameter .........................15
10. Security Considerations .......................................15
11. Acknowledgements ..............................................16
12. References ....................................................17
12.1. Normative References .....................................17
12.2. Informative References ...................................171. Introduction 🌈
Section 3.5 of SIP Outbound [RFC5626] defines two keep-alive mechanisms. Even though those keep-alive mechanisms are separated from the rest of SIP Outbound, SIP Outbound doesn't have a way to explicitly negotiate using them 🙈 Sometimes keep-alives do get implicitly negotiated as part of the SIP Outbound negotiation, though.
But there are SIP Outbound use-cases where keep-alives aren't implicitly negotiated as part of that process. There are also cases where SIP Outbound isn't supported or can't be applied, and people still need to negotiate keep-alives anyway. Last but not least, SIP Outbound only lets keep-alives be negotiated between a User Agent (UA) and an edge proxy, not between other SIP entities 😭
So this spec defines a new Session Initiation Protocol (SIP) [RFC3261] Via header field parameter, "keep", that lets adjacent SIP entities explicitly negotiate the NAT keep-alive mechanisms defined in SIP Outbound ✨ The "keep" parameter lets SIP entities say they're willing to send keep-alives, say they're willing to receive keep-alives, and (if they're willing to receive them) suggest a recommended keep-alive frequency 💜
Here are the use-cases where you'd need a way to explicitly negotiate keep-alives:
1.1. Use-Case: Dialog from Non-Registered UAs 🎀
Sometimes a User Agent Client (UAC) starts a dialog without registering first. But it still needs to keep NAT bindings open for the whole life of the dialog, so it has to be able to negotiate sending keep-alives toward its adjacent downstream SIP entity. A classic example is an emergency call, where you don't always have to register before calling 🚨
1.2. Use-Case: SIP Outbound Not Supported 🦋
Some SIP entities that need to negotiate keep-alives might not support SIP Outbound. They could still support the keep-alive mechanisms defined in SIP Outbound, though, and they still need a way to negotiate using them 💅
1.3. Use-Case: SIP Dialog Initiated Outbound Flows 🧚
SIP Outbound lets you set up flows using the initial request for a dialog. As specified in RFC 5626 [RFC5626], keep-alives are not implicitly negotiated for those flows 👑
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 RFC 5626, a SIP proxy that is located topologically between the registering User Agent (UA) and the Authoritative Proxy.
- NOTE: In some deployments, the edge proxy might be physically located in the same SIP entity as the Authoritative Proxy.
- Keep-alives: The keep-alive messages defined in RFC 5626.
- "keep" parameter: A SIP Via header field parameter that a SIP entity can insert in the topmost Via header field that it adds to the request, to explicitly indicate willingness to send keep-alives toward its adjacent downstream SIP entity. A SIP entity can add a parameter value to the "keep" parameter in a response to explicitly indicate willingness to receive keep-alives from its adjacent upstream SIP entity. 🎀
- SIP entity: SIP User Agent (UA), or proxy, as defined in RFC 3261.
- Adjacent downstream SIP entity: The adjacent SIP entity in the direction towards which a SIP request is sent.
- Adjacent upstream SIP entity: The adjacent SIP entity in the direction from which a SIP request is received.
4. User Agent and Proxy Behavior 🔥
4.1. General 💖
This section describes how SIP UAs and proxies negotiate keep-alives associated with a registration or a dialog. It covers which types of SIP requests can be used for the negotiation, and how long the negotiated keep-alives last ⏳
SIP entities say they're willing to send keep-alives toward the adjacent downstream SIP entity by using SIP requests. The responses are how SIP entities say they're willing to receive keep-alives. SIP entities that say they're willing to receive keep-alives can also give a recommended keep-alive frequency 🌸
The procedures for negotiating keep-alives are identical for SIP UAs and proxies. No difference, bestie 💅
Generally speaking, it can be really useful for SIP entities to say they're willing to send keep-alives, even if they don't know of any reason they'd need to. The adjacent downstream SIP entity might know about a necessity that they don't 🧠 In the same way, if the adjacent upstream SIP entity has said it's willing to send keep-alives, it can be useful to say you're willing to receive them, even if you aren't aware of any need for that upstream entity to send them ✨
- NOTE: Keep-alive usage is negotiated per direction. If a SIP entity has indicated willingness to receive keep-alives from an adjacent SIP entity, sending keep-alives toward that adjacent SIP entity needs to be negotiated separately 🙃
- NOTE: Some SIP entities already use a combination of Carriage Return and Line Feed (CRLF) as keep-alive messages, and SIP entities are expected to be able to receive those. So this spec doesn't forbid sending double-CRLF keep-alive messages toward an adjacent SIP entity, even when keep-alive usage with that entity hasn't been negotiated. The
"keep"parameter still matters, though 🫶 It's how a SIP entity indicates it supports sending double-CRLF keep-alive messages, so the adjacent downstream SIP entity doesn't reach for other mechanisms (e.g., short registration refresh intervals) to keep NAT bindings open 🦋
4.2. Lifetime of Keep-Alives ⏰
4.2.1. General
How long negotiated keep-alives last depends on whether they're associated with a registration or a dialog. This section describes that lifetime 💜
4.2.2. Keep-Alives Associated with Registration 🌷
SIP entities use a registration request to negotiate keep-alives associated with a registration. Keep-alive usage can be negotiated when the registration is established, or later during the registration. Once negotiated, keep-alives are sent until the registration is terminated, or until a subsequent registration refresh request is sent or forwarded. When a subsequent registration refresh request is sent or forwarded, if a SIP entity is willing to keep sending keep-alives associated with the registration, keep-alive usage MUST be re-negotiated. If usage is not successfully re-negotiated, the SIP entity MUST cease sending keep-alives associated with the registration. 🚫
- NOTE: Sending keep-alives associated with a registration can only be negotiated in the direction from the registering SIP entity towards the registrar. 🧚
Bestie, that's the end of part 1! 💖
4.2.3. Keep-Alives Associated with Dialog ✨
okay so SIP entities use an initial request for a dialog, or a mid-dialog target refresh request [RFC3261], to negotiate the sending and receiving of keep-alives for that dialog 💖. You can negotiate keep-alive usage when the dialog gets set up, or later on during its lifetime 🦋. Once it's negotiated, keep-alives MUST be sent for the whole lifetime of the dialog, until the dialog is terminated. And once keep-alive usage for a dialog has been negotiated, it's not possible to renegotiate it for that dialog, so no take-backs 💅
4.3. Behavior of a SIP Entity Willing to Send Keep-Alives 🎀
As defined in RFC 5626, a SIP entity that supports sending keep-alives must act as a Session Traversal Utilities for NAT (STUN) client [RFC5389]. It has to support the STUN aspects needed to apply the STUN keep-alive mechanism defined in RFC 5626, and it must support the CRLF keep-alive mechanism defined in RFC 5626. RFC 5626 is the one that spells out when to use STUN and when to use double-CRLF for keep-alives 🧚
When a SIP entity sends or forwards a request and wants to negotiate sending keep-alives for a registration or a dialog, it MUST insert a "keep" parameter in the topmost Via header field that it adds to the request. That's how it says "hey, I'm willing to send keep-alives" 📣
When the SIP entity gets the associated response, if the "keep" parameter in the topmost Via header field of the response contains a "keep" parameter value, it MUST start sending keep-alives towards the same destination where it would send a subsequent request (e.g., REGISTER requests and initial requests for dialog) associated with the registration (if the keep-alive negotiation is for a registration), or where it would send subsequent mid-dialog requests (if the keep-alive negotiation is for a dialog). Subsequent mid-dialog requests are addressed based on the dialog route set 🗺️
Once a SIP entity has negotiated keep-alives for a dialog towards an adjacent SIP entity, it MUST NOT insert a "keep" parameter in any subsequent SIP requests associated with that dialog towards that adjacent SIP entity. If it does receive such "keep" parameters, they MUST be ignored 🙈
An ACK request doesn't get a response, so it can't be used to negotiate keep-alive usage. That means a SIP entity MUST NOT insert a "keep" parameter in the topmost Via header field of an ACK request. If one shows up anyway, it MUST be ignored, if received 🙅♀️
A SIP entity MUST NOT indicate willingness to send keep-alives associated with a dialog, unless it has also inserted itself in the dialog route set [RFC3261]. No skipping the line 🍓
NOTE: When a SIP entity sends an initial request for a dialog, if the adjacent downstream SIP entity does not insert itself in the dialog route set using a Record-Route header field [RFC3261], the adjacent downstream SIP entity will change once the dialog route set has been established. If a SIP entity inserts a"keep"parameter in the topmost Via header field of an initial request for a dialog, and the"keep"parameter in the associated response does not contain a parameter value, the SIP entity might choose to insert a"keep"parameter in the topmost Via header field of a subsequent SIP request associated with the dialog, in case the new adjacent downstream SIP entity (based on the dialog route set) is willing to receive keep-alives (in which case it will add a parameter value to the"keep"parameter).
If an INVITE request is used to indicate willingness to send keep-alives, then as long as at least one response (provisional or final) to the INVITE request contains a "keep" parameter with a parameter value, that's seen as an indication that the adjacent downstream SIP entity is willing to receive keep-alives associated with the dialog on which the response is received 📞
4.4. Behavior of a SIP Entity Willing to Receive Keep-Alives 🌸
As defined in RFC 5626, a SIP entity that supports receiving keep-alives must act as a STUN server [RFC5389]. It must support the STUN aspects needed to apply the STUN keep-alive mechanism defined in RFC 5626, and it must support the CRLF keep-alive mechanism defined in RFC 5626 👑
When a SIP entity sends or forwards a response, and the adjacent upstream SIP entity has indicated willingness to send keep-alives, then if the SIP entity is willing to receive keep-alives associated with the registration or with the dialog from that adjacent upstream SIP entity, it MUST add a parameter value to the "keep" parameter before sending or forwarding the response. That parameter value, if present and not zero, is a recommended keep-alive frequency, given in seconds ⏱️
There might be multiple responses to an INVITE request. When a SIP entity indicates willingness to receive keep-alives in a response to an INVITE request, it MUST add a parameter value to the "keep" parameter in at least one reliable response to the request. The SIP entity MAY add identical parameter values to the "keep" parameters in other responses to the same request. What it MUST NOT do is add different parameter values to the "keep" parameters in responses to the same request. And it SHOULD indicate willingness to receive keep-alives as soon as possible 🏃♀️💨
A SIP entity MUST NOT indicate willingness to receive keep-alives associated with a dialog, unless it has also inserted itself in the dialog route set [RFC3261]. Same rule, opposite direction, still iconic 🫶
5. Keep-Alive Frequency 🌈
If a SIP entity receives a SIP response where the topmost Via header field contains a "keep" parameter with a non-zero value that indicates a recommended keep-alive frequency, given in seconds, it MUST use the procedures defined for the Flow-Timer header field [RFC5626]. Under those procedures, the SIP entity must send keep-alives at least as often as the indicated recommended keep-alive frequency. And if it uses the recommended keep-alive frequency, it should space its keep-alives so the interval between each one is randomly distributed between 80% and 100% of the recommended keep-alive frequency 🎲
If the received "keep" parameter value is zero, the SIP entity can send keep-alives at its discretion. RFC 5626 has more guidance on picking a keep-alive frequency when no recommended frequency is provided 🤓
This specification does not say what to do if negotiated keep-alives aren't received. As defined in RFC 5626, the receiving SIP entity may consider a connection to be dead in such situations 💀
If a SIP entity adds a parameter value to the "keep" parameter to show it's willing to receive keep-alives, and it also inserts a Flow-Timer header field in the same SIP message (which can happen if the entity is using both the Outbound mechanism and the keep-alive mechanism), the header field value and the "keep" parameter value MUST be identical. Matching outfits only 👗
SIP Outbound uses the Flow-Timer header field to indicate the server-recommended keep-alive frequency, but it will only be sent between a UA and an edge proxy. On the other hand, with the "keep" parameter, sending and receiving keep-alives can be negotiated between multiple entities on the signalling path. Plus, since the server-recommended keep-alive frequency might vary between different SIP entities, a single Flow-Timer header field can't be used to indicate all the different frequency values. So the "keep" parameter is the more flexible queen 👑✨
6. Connection Reuse 🔥
Keep-alives are often sent to keep NAT bindings open, so that SIP requests sent in the reverse direction will pass by the NAT and reuse the same connection. For non-connection-oriented transport protocols, keep-alives would permit the same path to be reused. This specification does not define a connection reuse mechanism, though. The keep-alive mechanism defined here is only used to negotiate the sending and receiving of keep-alives. Entities that want to reuse connections need another mechanism that makes sure the security aspects of connection reuse are taken into consideration 🔐
RFC 5923 [RFC5923] specifies a mechanism for using connection-oriented transports to send requests in the reverse direction. An entity that wants connection reuse and also wants to indicate keep-alive support on that connection will insert both the "alias" parameter defined in RFC 5923 and the "keep" parameter defined in this specification 🧩
SIP Outbound specifies how registration flows are used to send requests in the reverse direction 🔁
7. Examples 🧚
7.1. General 💅
This section shows example flows where keep-alive usage, associated with a registration and a dialog, is negotiated between different SIP entities. Let's see it in action 🎬
NOTE: The examples do not show the actual syntactical encoding of the request lines, response lines, and the Via header fields. They use pseudocode instead, so you can identify the message type and which SIP entity a Via header field is associated with 📝
7.2. Keep-Alive Negotiation Associated with Registration: UA-Proxy ✨
Okay so Figure 1 shows Alice sending a REGISTER request 💖 She says she's down to send keep-alives by popping a keep parameter into her Via header field. Then the edge proxy (P1) forwards the request towards the registrar 🦋
P1 is also down to receive keep-alives from Alice for the whole registration. So when the response comes back, P1 adds a keep parameter value to Alice's Via header field before passing it along. That value is a recommended keep-alive frequency of 30 seconds 🎀
When Alice gets the response, she checks her Via header field and sees that P1 is willing to receive keep-alives for the registration. Until either the registration expires or Alice sends a registration refresh request, she keeps sending periodic keep-alives towards P1 (here using the STUN keep-alive technique). She uses the frequency from the keep parameter value 🫶
Alice P1 REGISTRAR
| | |
|--- REGISTER------------->| |
| Via: Alice;keep | |
| |--- REGISTER-------------->|
| | Via: P1 |
| | Via: Alice;keep |
| | |
| |<-- 200 OK ----------------|
| | Via: P1 |
| | Via: Alice;keep |
|<-- 200 OK ---------------| |
| Via: Alice;keep=30 | |
| | |
| | |
| *** Timeout *** |
| | |
|=== STUN request ========>| |
|<== STUN response ========| |
| | |
| *** Timeout *** |
| | |
|=== STUN request ========>| |
|<== STUN response ========| |
| | |
Figure 1: Example Call Flow7.3. Keep-Alive Negotiation Associated with Dialog: UA-Proxy 🌸
Figure 2 is the same vibe but for a dialog 🧚 Alice sends an initial INVITE request for the dialog and drops a keep parameter into her Via header field to say she wants to send keep-alives. The edge proxy (P1) adds itself to the dialog route set by putting itself in a Record-Route header field, then forwards the request towards Bob 🦋
P1 is willing to receive keep-alives from Alice for the lifetime of the dialog. So when the associated response arrives, P1 adds a keep parameter value (a recommended keep-alive frequency of 30 seconds) to Alice's Via header field before forwarding it towards Alice 💜
When Alice receives the response, she reads her Via header field and learns that P1 is willing to receive keep-alives for the dialog. For the lifetime of the dialog, she then sends periodic keep-alives towards P1 (STUN keep-alive technique again, in this example) at the frequency from the keep parameter value ✨
Alice P1 Bob
| | |
|--- INVITE -------------->| |
| Via: Alice;keep | |
| |--- INVITE --------------->|
| | Via: P1 |
| | Via: Alice;keep |
| | Record-Route: P1 |
| | |
| |<-- 200 OK ----------------|
| | Via: P1 |
| | Via: Alice;keep |
| | Record-Route: P1 |
|<-- 200 OK ---------------| |
| Via: Alice;keep=30 | |
| Record-Route: P1 | |
| | |
|--- ACK ----------------->| |
| | |
| |--- ACK ------------------>|
| | |
| *** Timeout *** |
| | |
|=== STUN request ========>| |
|<== STUN response ========| |
| | |
| *** Timeout *** |
| | |
|=== STUN request ========>| |
|<== STUN response ========| |
| | |
| | |
|--- BYE ----------------->| |
| | |
| |--- BYE ------------------>|
| | |
| |<-- 200 OK ----------------|
| | |
Figure 2: Example Call Flow7.4. Keep-Alive Negotiation Associated with Dialog: UA-UA 💅
Figure 3 is the UA-UA version, and it's a bit of a plot twist 👑 Alice sends an initial INVITE and says she's willing to send keep-alives with a keep parameter in her Via header field. This time the edge proxy (P1) does not add itself to a Record-Route header field, so it isn't added to the dialog route set before it forwards the request towards Bob 🙈
When Alice gets the response, she checks the Via header field and sees that P1 is not willing to receive keep-alives associated with the dialog from her. Once the dialog route set is established, Alice sends a mid-dialog UPDATE request towards Bob (since P1 never put itself in the dialog route set). She once again says she's willing to send keep-alives by putting a keep parameter in her Via header field 🌈
Bob supports the keep-alive mechanism and is willing to receive keep-alives for the dialog from Alice. So he creates a response, adds a keep parameter value (a recommended keep-alive frequency of 30 seconds) to Alice's Via header field, and forwards the response towards Alice 🍓
When Alice receives that response, she sees from her Via header field that Bob is willing to receive keep-alives for the dialog. For the lifetime of the dialog, she then sends periodic keep-alives towards Bob (STUN keep-alive technique, in this example) at the frequency from the keep parameter value 🫶
Alice P1 Bob
| | |
|--- INVITE -------------->| |
| Via: Alice;keep | |
| |--- INVITE --------------->|
| | Via: P1 |
| | Via: Alice;keep |
| | |
| |<-- 200 OK ----------------|
| | Via: P1 |
| | Via: Alice;keep |
|<-- 200 OK ---------------| |
| Via: Alice;keep | |
| | |
| |
|--- ACK --------------------------------------------->|
| |
|--- UPDATE ------------------------------------------>|
| Via: Alice;keep |
| |
|<-- 200 OK -------------------------------------------|
| Via: Alice;keep=30 |
| |
| |
| *** Timeout *** |
| |
|=== STUN request ====================================>|
|<== STUN response ====================================|
| |
| *** Timeout *** |
| |
|=== STUN request ====================================>|
|<== STUN response ====================================|
| |
| |
|--- BYE --------------------------------------------->|
| |
|<-- 200 OK -------------------------------------------|
| |
Figure 3: Example Call Flow8. Grammar ✨
8.1. General 🎀
Here's the grammar bit 🤓 This section extends the ABNF definition of via-params from [RFC3261] by adding a brand-new Via header field parameter called "keep". The ABNF in this spec is conformant to RFC 5234 [RFC5234]. "EQUAL" is defined in RFC 3261, and "DIGIT" is defined in RFC 5234 💕
8.2. ABNF 💜
via-params =/ keep
keep = "keep" [ EQUAL 1*(DIGIT) ]9. IANA Considerations 🌸
9.1. "keep" Via Header Field Parameter 🦋
Okay, IANA stuff 📋 This specification defines a new Via header field parameter called "keep" in the "Header Field Parameters and Parameter Values" sub-registry, as per the registry created by [RFC3968]. The syntax is defined in Section 8 of this document. IANA has registered the following:
Predefined
Header Field Parameter Name Values Reference
---------------------- --------------------- ---------- ---------
Via keep No [RFC6223]10. Security Considerations 🔐
okay bestie, this part is serious but make it cute 🎀 SIP entities that send or receive keep-alives are often required to use a connection reuse mechanism. The point is that requests sent in the reverse direction, back towards the sender of the keep-alives, can get through NATs and friends 🦋. This spec does not define a connection reuse mechanism, and it does not cover security issues related to connection reuse 💀. If you want to reuse connections, you need a dedicated connection reuse mechanism, used together with the keep-alive negotiation mechanism 💅.
Unless SIP messages are integrity protected hop-by-hop, for example with Transport Layer Security (TLS) [RFC5246] or Datagram Transport Layer Security (DTLS) [RFC4347], a man-in-the-middle can mess with the Via header fields that two entities use to negotiate keep-alives 😭. They could remove the markers that say "yes, I'm willing to send and receive keep-alives," or they could drop the timer value to something super low. That might trigger extra resource consumption because the keep-alives get sent way too often 🔥.
The behaviours in Sections 4.3 and 4.4 require a SIP entity using this mechanism to put a value in the keep parameter of the topmost Via header field value in a response that the entity sends ✨. They do not tell the entity to put a value in a keep parameter of any request it forwards. In particular, a SIP proxy MUST NOT place a value into the keep parameter of the topmost Via header field value of a request it receives before forwarding it 🙅♀️. A SIP proxy implementing this specification SHOULD remove any keep parameter values in any Via header field values below the topmost one in responses it receives before forwarding them 🧹.
When requests get forwarded across multiple hops, a malicious downstream SIP entity could tamper with the Via header field values that have built up along the way 👀. That sneaky entity could place a value in a keep parameter, or change an existing one, in any of the Via header field values, not just the topmost one. A proxy that simply forwards responses by stripping the topmost Via header field value, without inspecting the new topmost one, could get messed up by this 😱. In particular, such a proxy might start receiving STUN requests if it blindly forwards a response with a keep parameter holding a value it did not create in the topmost Via header field.
To lower the chances of that malicious entity causing trouble for those proxies, here's the rule 🫶: when a SIP entity sends STUN keep-alives to an adjacent downstream SIP entity and does not get a response to those STUN messages (as described in Section 7.2.1 of RFC 5389 [RFC5389], it MUST stop sending keep-alives for the remaining duration of the dialog (if the sending of keep-alives was negotiated for a dialog), or until the sending of keep-alives is re-negotiated for the registration (if the sending of keep-alives was negotiated for a registration).
Apart from the issues described above, this specification doesn't add any security considerations beyond the ones already specified for keep-alives in [RFC5626] 🌸.
11. Acknowledgements 🙏
Big thank you to Staffan Blau, Francois Audet, Hadriel Kaplan, Sean Schneyer, and Milo Orsic for their comments on the initial draft version of this document 💜. Thanks also to Juha Heinanen, Jiri Kuthan, Dean Willis, John Elwell, Paul Kyzivat, Peter Musgrave, Dale Worley, Adam Roach, and Robert Sparks for their comments on the sipcore mailing list 📬. And a special shout-out to Vijay Gurbani for providing the text about the relationship with the connect reuse specification 🧚✨.
12. References 📚
12.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.
- [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
- [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
- [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
12.2. Informative References
- [RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
- [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
- [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
- [RFC5923] Gurbani, V., Ed., Mahy, R., and B. Tate, "Connection Reuse in the Session Initiation Protocol (SIP)", RFC 5923, June 2010.
Author's Address 🦋
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: christer.holmberg@ericsson.com📦 where this page comes from
- ietf: rfc6223 2011-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms