From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4028.txt | 1515 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1515 insertions(+) create mode 100644 doc/rfc/rfc4028.txt (limited to 'doc/rfc/rfc4028.txt') diff --git a/doc/rfc/rfc4028.txt b/doc/rfc/rfc4028.txt new file mode 100644 index 0000000..ecec689 --- /dev/null +++ b/doc/rfc/rfc4028.txt @@ -0,0 +1,1515 @@ + + + + + + +Network Working Group S. Donovan +Request for Comments: 4028 J. Rosenberg +Category: Standards Track Cisco Systems + April 2005 + + + Session Timers in the Session Initiation Protocol (SIP) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document defines an extension to the Session Initiation Protocol + (SIP). This extension allows for a periodic refresh of SIP sessions + through a re-INVITE or UPDATE request. The refresh allows both user + agents and proxies to determine whether the SIP session is still + active. The extension defines two new header fields: + Session-Expires, which conveys the lifetime of the session, and + Min-SE, which conveys the minimum allowed value for the session + timer. + + + + + + + + + + + + + + + + + + + + + +Donovan & Rosenberg Standards Track [Page 1] + +RFC 4028 Session Timer April 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Overview of Operation . . . . . . . . . . . . . . . . . . . 4 + 4. Session-Expires Header Field Definition . . . . . . . . . . 6 + 5. Min-SE Header Field Definition . . . . . . . . . . . . . . . 8 + 6. 422 Response Code Definition . . . . . . . . . . . . . . . . 8 + 7. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . 9 + 7.1. Generating an Initial Session Refresh Request . . . . 9 + 7.2. Processing a 2xx Response . . . . . . . . . . . . . . 9 + 7.3. Processing a 422 Response . . . . . . . . . . . . . . 11 + 7.4. Generating Subsequent Session Refresh Requests . . . . 11 + 8. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 12 + 8.1. Processing of Requests . . . . . . . . . . . . . . . . 13 + 8.2. Processing of Responses . . . . . . . . . . . . . . . 14 + 8.3. Session Expiration . . . . . . . . . . . . . . . . . . 15 + 9. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . 15 + 10. Performing Refreshes . . . . . . . . . . . . . . . . . . . . 17 + 11. Security Considerations . . . . . . . . . . . . . . . . . . 18 + 11.1. Inside Attacks . . . . . . . . . . . . . . . . . . . . 18 + 11.2. Outside Attacks . . . . . . . . . . . . . . . . . . . 19 + 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 + 12.1. IANA Registration of Min-SE and Session-Expires + Header Fields . . . . . . . . . . . . . . . . . . . . 19 + 12.2. IANA Registration of the 422 (Session Interval Too + Small) Response Code . . . . . . . . . . . . . . . . . 20 + 12.3. IANA Registration of the 'timer' Option Tag . . . . . 20 + 13. Example Call Flow . . . . . . . . . . . . . . . . . . . . . 20 + 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 + 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 15.1. Normative References . . . . . . . . . . . . . . . . . 25 + 15.2. Informative References . . . . . . . . . . . . . . . . 26 + Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 26 + Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 27 + +1. Introduction + + The Session Initiation Protocol (SIP) [2] does not define a keepalive + mechanism for the sessions it establishes. Although the user agents + may be able to determine whether the session has timed out by using + session specific mechanisms, proxies will not be able to do so. The + result is that call stateful proxies will not always be able to + determine whether a session is still active. For instance, when a + user agent fails to send a BYE message at the end of a session, or + when the BYE message gets lost due to network problems, a call + stateful proxy will not know when the session has ended. In this + situation, the call stateful proxy will retain state for the call and + + + +Donovan & Rosenberg Standards Track [Page 2] + +RFC 4028 Session Timer April 2005 + + + has no method to determine when the call state information no longer + applies. + + To resolve this problem, this extension defines a keepalive mechanism + for SIP sessions. UAs send periodic re-INVITE or UPDATE [3] requests + (referred to as session refresh requests) to keep the session alive. + The interval for the session refresh requests is determined through a + negotiation mechanism defined here. If a session refresh request is + not received before the interval passes, the session is considered + terminated. Both UAs are supposed to send a BYE, and call stateful + proxies can remove any state for the call. + + This refresh mechanism has additional applications. A user agent + would like to determine whether the session is still active for the + same reasons a call stateful proxy server would. This determination + can be made at a user agent without the use of SIP level mechanisms; + for audio sessions, periodic RTCP packets serve as an indication of + liveness [5]. However, it is desirable to separate indications of + SIP session liveness from the details of the particular session. + + Another application of the session timer is in the construction of a + SIP Network Address Translator (NAT) Application Level Gateway (ALG) + [6]. The ALG embedded in a NAT will need to maintain state for the + duration of a call. This state must eventually be removed. Relying + on a BYE to trigger the removal of state, besides being unreliable, + introduces a potential denial of service attack. + + This document provides an extension to SIP that defines a session + expiration mechanism. Periodic refreshes, through re-INVITEs or + UPDATEs, are used to keep the session active. The extension is + sufficiently backward compatible with SIP that it works as long as + either one of the two participants in a dialog understands the + extension. Two new header fields (Session-Expires and Min-SE) and a + new response code (422) are defined. Session-Expires conveys the + duration of the session, and Min-SE conveys the minimum allowed value + for the session expiration. The 422 response code indicates that the + session timer duration was too small. + +2. Terminology + + In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED', + 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', + and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1] and + indicate requirement levels for compliant SIP implementations. + + + + + + + +Donovan & Rosenberg Standards Track [Page 3] + +RFC 4028 Session Timer April 2005 + + + Additionally, we define the following terms: + + Session Interval: The maximum amount of time that can occur between + session refresh requests in a dialog before the session will be + considered timed out. The session interval is conveyed in the + Session-Expires header field, which is defined here. The UAS + obtains this value from the Session-Expires header field in a 2xx + response to a session refresh request that it sends. Proxies and + UACs determine this value from the Session-Expires header field in + a 2xx response to a session refresh request that they receive. + + Minimum Timer: Because of the processing load of mid-dialog requests, + all elements (proxy, UAC, UAS) can have a configured minimum value + for the session interval that they are willing to accept. This + value is called the minimum timer. + + Session Expiration: The time at which an element will consider the + session timed out, if no successful session refresh transaction + occurs beforehand. + + Session Refresh Request: An INVITE or UPDATE request processed + according to the rules of this specification. If the request + generates a 2xx response, the session expiration is increased to + the current time plus the session interval obtained from the + response. A session refresh request is not to be confused with a + target refresh request, defined in Section 6 of [2], which is a + request that can update the remote target of a dialog. + + Initial Session Refresh Request: The first session refresh request + sent with a particular Call-ID value. + + Subsequent Session Refresh Request: Any session refresh request sent + with a particular Call-ID after the initial session refresh + request. + + Refresh: Same as a session refresh request. + +3. Overview of Operation + + This section provides a brief overview of the operation of the + extension. It is tutorial in nature and should not be considered + normative. + + This extension has the property that it works even when only one UA + in a dialog supports it. The processing steps differ for handling + each of the four cases (the UAC does or doesn't support it, and the + UAS does or doesn't support it). For simplicity's sake, this section + + + + +Donovan & Rosenberg Standards Track [Page 4] + +RFC 4028 Session Timer April 2005 + + + will describe basic operation in the case where both sides support + the extension. + + A UAC starts by sending an INVITE. This includes a Supported header + field with the option tag 'timer', indicating support for this + extension. + + This request passes through proxies, any one of which may have an + interest in establishing a session timer. Each proxy can insert a + Session-Expires header field and a Min-SE header field into the + request (if none is already there) or alter the value of existing + Session-Expires and Min-SE header fields as described below. + + The Min-SE header field establishes the lower bound for the session + refresh interval; i.e., the fastest rate any proxy servicing this + request will be allowed to require. The purpose of this header field + is to prevent hostile proxies from setting arbitrarily short refresh + intervals so that their neighbors are overloaded. Each proxy + processing the request can raise this lower bound (increase the + period between refreshes) but is not allowed to lower it. + + The Session-Expires header field establishes the upper bound for the + session refresh interval; i.e., the time period after processing a + request for which any session-stateful proxy must retain its state + for this session. Any proxy servicing this request can lower this + value, but it is not allowed to decrease it below the value specified + in the Min-SE header field. + + If the Session-Expires interval is too low for a proxy (i.e., lower + than the value of Min-SE that the proxy would wish to assert), the + proxy rejects the request with a 422 response. That response + contains a Min-SE header field identifying the minimum session + interval it is willing to support. The UAC will try again, this time + including the Min-SE header field in the request. The header field + contains the largest Min-SE header field it observed in all 422 + responses previously received. This way, the minimum timer meets the + constraints of all proxies along the path. + + After several INVITE/422 iterations, the request eventually arrives + at the UAS. The UAS can adjust the value of the session interval as + if it were a proxy; when done, it places the final session interval + into the Session-Expires header field in a 2xx response. The + Session-Expires header field also contains a 'refresher' parameter, + which indicates who is doing the refreshing -- the UA that is + currently the UAC, or the UA that is currently the UAS. As the 2xx + response travels back through the proxy chain, each proxy can observe + the final session interval but can't change it. + + + + +Donovan & Rosenberg Standards Track [Page 5] + +RFC 4028 Session Timer April 2005 + + + From the Session-Expires header field in the response, both UAs know + that a session timer is active, when it will expire, and who is + refreshing. At some point before the expiration, the currently + active refresher generates a session refresh request, which is a + re-INVITE or UPDATE [3] request. If the refresher never gets a + response to that session refresh request, it sends a BYE to terminate + the session. Similarly, if the other side never gets the session + refresh request before the session expires, it sends a BYE. + + The refresh requests sent once the session is established are + processed identically to the initial requests, as described above. + This means that a successful session refresh request will extend the + session, as desired. + + The extension introduces additional complications beyond this basic + flow to support cases where only one of the UAs supports it. One + such complication is that a proxy may need to insert the + Session-Expires header field into the response, in the event that the + UAS doesn't support the extension. The negotiation of the role of + refresher is also affected by this capability; it takes into + consideration which participants support the extension. + + Note that the session timer refreshes the session, not the dialog + used to establish the session. Of course, the two are related. If + the session expires, a BYE is sent, which terminates the session and, + generally, the dialog. + +4. Session-Expires Header Field Definition + + The Session-Expires header field conveys the session interval for a + SIP session. It is placed only in INVITE or UPDATE requests, as well + as in any 2xx response to an INVITE or UPDATE. Like the SIP Expires + header field, it contains a delta-time. + + The absolute minimum for the Session-Expires header field is 90 + seconds. This value represents a bit more than twice the duration + that a SIP transaction can take in the event of a timeout. This + allows sufficient time for a UA to attempt a refresh at the halfpoint + of the session interval, and for that transaction to complete + normally before the session expires. However, 1800 seconds (30 + minutes) is RECOMMENDED as the value for the Session-Expires header + field. In other words, SIP entities MUST be prepared to handle + Session-Expires header field values of any duration greater than 90 + seconds, but entities that insert the Session-Expires header field + SHOULD NOT choose values of less than 30 minutes. + + + + + + +Donovan & Rosenberg Standards Track [Page 6] + +RFC 4028 Session Timer April 2005 + + + Small session intervals can be destructive to the network. They + cause excessive messaging traffic that affects both user agents and + proxy servers. They increase the possibility of 'glare' that can + occur when both user agents send a re-INVITE or UPDATE at the same + time. Since the primary purpose of the session timer is to provide a + means to time out state in SIP elements, very small values won't + generally be needed. 30 minutes was chosen because 95% of phone + calls are shorter than this duration. However, the 30 minute minimum + is listed as a SHOULD, and not as a MUST, since the exact value for + this number is dependent on many network factors, including network + bandwidths and latencies, computing power, memory availability, + network topology, and, of course, the application scenario. After + all, SIP can set up any kind of session, not just a phone call. At + the time of publication of this document, 30 minutes seems + appropriate. Advances in technologies may result in the number being + excessively large five years in the future. + + The default value of the Session-Expires header field is undefined. + This means that the absence of the Session-Expires header field + implies no expiration of the session, using the mechanism defined in + this specification. Note that other mechanisms not defined in this + specification, such as locally configured timers, may apply. + + The syntax of the Session-Expires header field is as follows: + + Session-Expires = ("Session-Expires" / "x") HCOLON delta-seconds + *(SEMI se-params) + se-params = refresher-param / generic-param + refresher-param = "refresher" EQUAL ("uas" / "uac") + + Note that a compact form, the letter x, has been reserved for + Session-Expires. The BNF for delta-seconds and generic-param is + defined in Section 25 of RFC 3261 [2]. + + Table 1 is an extension of Tables 2 and 3 in [2] for the + Session-Expires and Min-SE header fields. The column 'PRA' is for + the PRACK method [7], 'UPD' is for the UPDATE method [3], 'SUB' is + for the SUBSCRIBE method [8], and 'NOT' is for the NOTIFY method [8]. + + + + + + + + + + + + + +Donovan & Rosenberg Standards Track [Page 7] + +RFC 4028 Session Timer April 2005 + + + +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ + | Header |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT| + +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ + |Session-Expires| R | amr | - | - | - | o | - | - | - | o | - | - | + | | | | | | | | | | | | | | + |Session-Expires| 2xx | ar | - | - | - | o | - | - | - | o | - | - | + | | | | | | | | | | | | | | + |Min-SE | R | amr | - | - | - | o | - | - | - | o | - | - | + | | | | | | | | | | | | | | + |Min-SE | 422 | | - | - | - | m | - | - | - | m | - | - | + +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ + + Table 1: Session-Expires and Min-SE Header Fields + +5. Min-SE Header Field Definition + + The Min-SE header field indicates the minimum value for the session + interval, in units of delta-seconds. When used in an INVITE or + UPDATE request, it indicates the smallest value of the session + interval that can be used for that session. When present in a + request or response, its value MUST NOT be less than 90 seconds. + + When the header field is not present, its default value for is 90 + seconds. + + The Min-SE header field MUST NOT be used in responses except for + those with a 422 response code. It indicates the minimum value of + the session interval that the server is willing to accept. + + The syntax of the Min-SE header field is as follows: + + Min-SE = "Min-SE" HCOLON delta-seconds *(SEMI generic-param) + +6. 422 Response Code Definition + + This extension introduces the 422 (Session Interval Too Small) + response code. It is generated by a UAS or proxy when a request + contains a Session-Expires header field with a duration below the + minimum timer for the server. The 422 response MUST contain a Min-SE + header field with the minimum timer for that server. + + + + + + + + + + + +Donovan & Rosenberg Standards Track [Page 8] + +RFC 4028 Session Timer April 2005 + + +7. UAC Behavior + +7.1. Generating an Initial Session Refresh Request + + A UAC that supports the session timer extension defined here MUST + include a Supported header field in each request (except ACK), + listing the option tag 'timer' [2]. It MUST do so even if the UAC is + not requesting usage of the session timer for this session. + + The UAC MAY include a Require header field in the request with the + value 'timer' to indicate that the UAS must support the session timer + to participate in the session. This does not mean that the UAC is + requiring the UAS to perform the refreshes, only that it is requiring + the UAS to support the extension. In addition, the UAC MAY include a + Proxy-Require header field in the request with the value 'timer' to + indicate that proxies must support the session timer in order to + correctly process the request. However, usage of either Require or + Proxy-Require by the UAC is NOT RECOMMENDED. They are not needed, + since the extension works even when only the UAC supports the + extension. The Supported header field containing 'timer' MUST still + be included, even if the Require or Proxy-Require header fields are + present containing 'timer'. + + A UAC MAY include the Min-SE header field in the initial INVITE + request. + + A UAC MAY include a Session-Expires header field in an initial + session refresh request if it wants a session timer applied to the + session. The value of this header field indicates the session + interval desired by the UAC. If a Min-SE header is included in the + initial session refresh request, the value of the Session-Expires + MUST be greater than or equal to the value in Min-SE. + + The UAC MAY include the refresher parameter with value 'uac' if it + wants to perform the refreshes. However, it is RECOMMENDED that the + parameter be omitted so that it can be selected by the negotiation + mechanisms described below. + +7.2. Processing a 2xx Response + + The session timer requires a UA to create and maintain state. This + state includes the session interval, the session expiration, and the + identity of the refresher. This state is associated with the dialog + on which the session has been negotiated. + + + + + + + +Donovan & Rosenberg Standards Track [Page 9] + +RFC 4028 Session Timer April 2005 + + + When a 2xx response to a session refresh request arrives, it may or + may not contain a Require header field with the value 'timer'. If it + does, the UAC MUST look for the Session-Expires header field to + process the response. + + If there was a Require header field in the response with the value + 'timer', the Session-Expires header field will always be present. + UACs MUST be prepared to receive a Session-Expires header field in a + response, even if none were present in the request. The 'refresher' + parameter will be present in the Session-Expires header field, + indicating who will perform the refreshes. The UAC MUST set the + identity of the refresher to the value of this parameter. If the + parameter contains the value 'uac', the UAC will perform them. It is + possible that the UAC requested the session timer (and thus included + a Session-Expires header field in the request) and that there was no + Require or Session-Expires header field in the 2xx response. This + will happen when the UAS doesn't support the session timer extension + and only the UAC has asked for a session timer (no proxies have + requested it). In this case, if the UAC still wishes to use the + session timer (which is purely for its benefit alone), it has to + perform them. To do this, the UAC follows the procedures defined in + this specification as if the Session-Expires header field were in the + 2xx response, and its value was the same as that in the request, but + with a refresher parameter of 'uac'. + + If the 2xx response did not contain a Session-Expires header field, + there is no session expiration. In this case, no refreshes need to + be sent. A 2xx without a Session-Expires can come for both initial + and subsequent session refresh requests. This means that the session + timer can be 'turned-off' in mid dialog by receiving a response + without a Session-Expires header field. + + The UAC remembers the session interval for a session as the value of + the delta-time from the Session-Expires header field in the most + recent 2xx response to a session refresh request on a dialog. It is + explicitly allowed for there to be differing session intervals (or + none at all) on differing dialogs established as a result of a single + INVITE. The UAC also remembers whether it or its peer is the + refresher on for the session. + + If the UAC must perform the refreshes, it computes the session + expiration for that session. The session expiration is the time of + reception of the last 2xx response to a session refresh request on + that dialog plus the session interval for that session. If the UA + seeks to continue with the session beyond the session expiration, it + MUST generate a refresh before the session expiration. It is + + + + + +Donovan & Rosenberg Standards Track [Page 10] + +RFC 4028 Session Timer April 2005 + + + RECOMMENDED that this refresh be sent once half the session interval + has elapsed. Additional procedures for this refresh are described in + Section 10. + + Similarly, a re-INVITE or UPDATE request sent within a dialog for + purposes other than session refreshes will also have the effect of + refreshing the session, and its processing will follow the procedures + defined in this specification. + +7.3. Processing a 422 Response + + If the response to a session refresh request is a 422 (Session + Interval Too Small) response message, then the UAC MAY retry the + request. The procedures for retrying are described in Section 7.4. + This new request constitutes a new transaction and SHOULD have the + same value as the Call-ID, To, and From of the previous request, but + the CSeq should contain a new sequence number that is one higher than + the previous. + +7.4. Generating Subsequent Session Refresh Requests + + The values of Supported, Require, and Proxy-Require used in the + initial Session refresh request MUST be used. + + The UAC MUST insert the Min-SE header field into a session refresh + request for a particular dialog if it has ever received a 422 + response to a previous session refresh request on the same dialog, or + if it has received a session refresh request on that dialog that + contained a Min-SE header field. Similarly, if no dialog has been + established yet, a UAC MUST insert the Min-SE header field into an + INVITE request if it has ever received a 422 response to a previous + INVITE request with the same Call-ID. + + The value of the Min-SE header field present in a session refresh + request MUST be the largest value among all Min-SE header field + values returned in all 422 responses or received in session refresh + requests, on the same dialog, if a dialog has been established. If + no dialog has been established, the Min-SE header field value is set + to the largest value among all Min-SE header field values returned in + all 422 responses for an INVITE request with the same Call-ID. A + result of this rule is that the maximum value of the Min-SE is + effectively 'cleared' once the dialog is established, and from that + point on, only the values from proxies known to be on the proxy path + will end up being used. + + The UAC may have its own opinions about the minimum session interval. + In that case, if the value above is too small, the UAC MAY increase + it. + + + +Donovan & Rosenberg Standards Track [Page 11] + +RFC 4028 Session Timer April 2005 + + + In a session refresh request sent within a dialog with an active + session timer, the Session-Expires header field SHOULD be present. + When present, it SHOULD be equal to the maximum of the Min-SE header + field (recall that its default value when not present is 90 seconds) + and the current session interval. Inclusion of the Session-Expires + header field with this value avoids certain denial-of-service + attacks, as documented in Section 11. As such, a UA should only + ignore the SHOULD in unusual and singular cases where it is desirable + to change the session interval mid-dialog. + + If the session refresh request is not the initial one, it is + RECOMMENDED that the refresher parameter be set to 'uac' if the + element sending the request is currently performing refreshes, and to + 'uas' if its peer is performing the refreshes. This way, the role of + refresher does not change on each refresh. However, if it wishes to + explicitly change the roles, it MAY use a value of 'uas' if it knows + that the other side supports the session timer. It could know this + by having received a request from its peer with a Supported header + field containing the value 'timer'. If it seeks to reselect the + roles, it MAY omit the parameter. + + A re-INVITE generated to refresh the session is a normal re-INVITE, + and an UPDATE generated to refresh a session is a normal UPDATE. If + a UAC knows that its peer supports the UPDATE method, it is + RECOMMENDED that UPDATE be used instead of a re-INVITE. A UA can + make this determination if it has seen an Allow header field from its + peer with the value 'UPDATE', or through a mid-dialog OPTIONS + request. It is RECOMMENDED that the UPDATE request not contain an + offer [4], but a re-INVITE SHOULD contain one, even if the details of + the session have not changed. In that case, the offer MUST indicate + that it has not changed. In the case of SDP, this is accomplished by + including the same value for the origin field as did previous SDP + messages to its peer. The same is true for an answer exchanged as a + result of a session refresh request; if it has not changed, that MUST + be indicated. + +8. Proxy Behavior + + Session timers are mostly of interest to call stateful proxy servers + (that is, to servers that maintain the state of calls and dialogs + established through them). However, a stateful proxy server (that + is, a server which is aware of transaction state but does not retain + call or dialog state) MAY also follow the rules described here. + Stateless proxies MUST NOT attempt to request session timers. + Proxies that ask for session timers SHOULD record-route, as they + won't receive refreshes if they don't. + + + + + +Donovan & Rosenberg Standards Track [Page 12] + +RFC 4028 Session Timer April 2005 + + + The proxy processing rules require the proxy to remember + information between the request and response, ruling out stateless + proxies. + +8.1. Processing of Requests + + Processing of requests is identical for all session refresh requests. + + To request a session timer for a session, a proxy makes sure that a + Session-Expires header field is present in a session refresh request + for that session. A proxy MAY insert a Session-Expires header field + in the request before forwarding it if none was present in the + request. This Session-Expires header field may contain any desired + expiration time the proxy would like, but not with a duration lower + than the value in the Min-SE header field in the request, if it is + present. The proxy MUST NOT include a refresher parameter in the + header field value. + + If the request already had a Session-Expires header field, the proxy + MAY reduce its value but MUST NOT set it to a duration lower than the + value in the Min-SE header field in the request, if it is present. + If the value of the Session-Expires header field is greater than or + equal to the value in the Min-SE header field (recall that the + default is 90 seconds when the Min-SE header field is not present), + the proxy MUST NOT increase the value of the Session-Expires header + field. If the value of the Session-Expires header field is lower + than the value of the Min-SE header field (possibly because the proxy + increased the value of the Min-SE header field, as described below), + the proxy MUST increase the value of the Session-Expires header field + to make it equal to Min-SE header field value. The proxy MUST NOT + insert or modify the value of the 'refresher' parameter in the + Session-Expires header field. + + If the request contains a Supported header field with a value + 'timer', the proxy MAY reject the INVITE request with a 422 (Session + Interval Too Small) response if the session interval in the + Session-Expires header field is smaller than the minimum interval + defined by the proxy's local policy. When sending the 422 response, + the proxy MUST include a Min-SE header field with the value of its + minimum interval. That minimum MUST NOT be lower than 90 seconds. + + If the request doesn't indicate support for the session timer but + contains a session interval that is too small, the proxy cannot + usefully reject the request, as this would result in a call failure. + Rather, the proxy SHOULD insert a Min-SE header field containing its + minimum interval. If a Min-SE header field is already present, the + proxy SHOULD increase (but MUST NOT decrease) the value to its + minimum interval. The proxy MUST then increase the Session-Expires + + + +Donovan & Rosenberg Standards Track [Page 13] + +RFC 4028 Session Timer April 2005 + + + header field value to be equal to the value in the Min-SE header + field, as described above. A proxy MUST NOT insert a Min-SE header + field or modify the value of an existing header field in a proxied + request if that request contains a Supported header field with the + value 'timer'. This is needed to protect against certain denial of + service attacks, described in Section 11. + + Assuming that the proxy has requested a session timer (and thus has + possibly inserted the Session-Expires header field or reduced it), + the proxy MUST remember that it is using a session timer, and also + remember the value of the Session-Expires header field from the + proxied request. This MUST be remembered for the duration of the + transaction. + + The proxy MUST remember, for the duration of the transaction, whether + the request contained the Supported header field with the value + 'timer'. If the request did not contain a Supported header field + with the value 'timer', the proxy MAY insert a Require header field + with the value 'timer' into the request. However, this is NOT + RECOMMENDED. This allows the proxy to insist on a session timer for + the session. This header field is not needed if a Supported header + field was in the request; in this case, the proxy would already be + sure the session timer can be used for the session. + +8.2. Processing of Responses + + When the final response to the request arrives, it is examined by the + proxy. + + If the response does not contain a Session-Expires header field but + the proxy remembers that it requested a session timer in the request + (by inserting, modifying, or examining and accepting the + Session-Expires header field in the proxied request), this means that + the UAS did not support the session timer. If the proxy remembers + that the UAC did not support the session timer either, the proxy + forwards the response upstream normally. There is no session + expiration for this session. If, however, the proxy remembers that + the UAC did support the session timer, additional processing is + needed. + + Because there is no Session-Expires or Require header field in the + response, the proxy knows that it is the first session-timer-aware + proxy to receive the response. This proxy MUST insert a + Session-Expires header field into the response with the value it + remembered from the forwarded request. It MUST set the value of the + 'refresher' parameter to 'uac'. The proxy MUST add the 'timer' + + + + + +Donovan & Rosenberg Standards Track [Page 14] + +RFC 4028 Session Timer April 2005 + + + option tag to any Require header field in the response, and if none + was present, add the Require header field with that value before + forwarding it upstream. + + If the received response contains a Session-Expires header field, no + modification of the response is needed. + + In all cases, if the 2xx response forwarded upstream by the proxy + contains a Session-Expires header field, its value represents the + session interval for the session associated with that response. The + proxy computes the session expiration as the time when the 2xx + response is forwarded upstream, plus the session interval. This + session expiration MUST update any existing session expiration for + the session. The refresher parameter in the Session-Expires header + field in the 2xx response forwarded upstream will be present, and it + indicates which UA is performing the refreshes. There can be + multiple 2xx responses to a single INVITE, each representing a + different dialog, resulting in multiple session expirations, one for + each session associated with each dialog. + + The proxy MUST NOT modify the value of the Session-Expires header + field received in the response (assuming one was present) before + forwarding it upstream. + +8.3. Session Expiration + + When the current time equals or passes the session expiration for a + session, the proxy MAY remove associated call state, and MAY free any + resources associated with the call. Unlike the UA, it MUST NOT send + a BYE. + +9. UAS Behavior + + The UAS must respond to a request for a session timer by the UAC or a + proxy in the path of the request, or it may request that a session + timer be used itself. + + If an incoming request contains a Supported header field with a value + 'timer' and a Session Expires header field, the UAS MAY reject the + INVITE request with a 422 (Session Interval Too Small) response if + the session interval in the Session-Expires header field is smaller + than the minimum interval defined by the UAS' local policy. When + sending the 422 response, the UAS MUST include a Min-SE header field + with the value of its minimum interval. This minimum interval MUST + NOT be lower than 90 seconds. + + If the UAS wishes to accept the request, it copies the value of the + Session-Expires header field from the request into the 2xx response. + + + +Donovan & Rosenberg Standards Track [Page 15] + +RFC 4028 Session Timer April 2005 + + + The UAS response MAY reduce its value but MUST NOT set it to a + duration lower than the value in the Min-SE header field in the + request, if it is present; otherwise the UAS MAY reduce its value but + MUST NOT set it to a duration lower than 90 seconds. The UAS MUST + NOT increase the value of the Session-Expires header field. + + If the incoming request contains a Supported header field with a + value 'timer' but does not contain a Session-Expires header, it means + that the UAS is indicating support for timers but is not requesting + one. The UAS may request a session timer in the 2XX response by + including a Session-Expires header field. The value MUST NOT be set + to a duration lower than the value in the Min-SE header field in the + request, if it is present. + + The UAS MUST set the value of the refresher parameter in the + Session-Expires header field in the 2xx response. This value + specifies who will perform refreshes for the dialog. The value is + based on the value of this parameter in the request, and on whether + the UAC supports the session timer extension. The UAC supports the + extension if the 'timer' option tag was present in a Supported header + field in the request. Table 2 defines how the value in the response + is set. A value of 'none' in the 2nd column means that there was no + refresher parameter in the request. A value of 'NA' in the third + column means that this particular combination shouldn't happen, as it + is disallowed by the protocol. + + UAC supports? refresher parameter refresher parameter + in request in response + ------------------------------------------------------- + N none uas + N uac NA + N uas NA + Y none uas or uac + Y uac uac + Y uas uas + + Table 2: UAS Behavior + + The fourth row of Table 2 describes a case where both the UAC and UAS + support the session timer extension, and where the UAC did not select + who will perform refreshes. This allows the UAS to decide whether it + or the UAC will perform the refreshes. However, as the table + indicates, the UAS cannot override the UAC's choice of refresher, if + it made one. + + If the refresher parameter in the Session-Expires header field in the + 2xx response has a value of 'uac', the UAS MUST place a Require + header field into the response with the value 'timer'. This is + + + +Donovan & Rosenberg Standards Track [Page 16] + +RFC 4028 Session Timer April 2005 + + + because the uac is performing refreshes and the response has to be + processed for the UAC to know this. If the refresher parameter in + the 2xx response has a value of 'uas' and the Supported header field + in the request contained the value 'timer', the UAS SHOULD place a + Require header field into the response with the value 'timer'. In + this case, the UAC is not refreshing, but it is supposed to send a + BYE if it never receives a refresh. Since the call will still + succeed without the UAC sending a BYE, insertion of the Require is a + SHOULD here, and not a MUST. + + Just like the UAC, the UAS stores state for the session timer. This + state includes the session interval, the session expiration, and the + identity of the refresher. This state is bound to the dialog used to + set up the session. The session interval is set to the value of the + delta-time from the Session-Expires header field in the most recent + 2xx response to a session refresh request on that dialog. It also + remembers whether it or its peer is the refresher on the dialog, + based on the value of the refresher parameter from the most recent + 2xx response to a session refresh request on that dialog. If the + most recent 2xx response had no Session-Expires header field, there + is no session expiration, and no refreshes have to be performed. + + If the UAS must refresh the session, it computes the session + expiration. The session expiration is the time of transmission of + the last 2xx response to a session refresh request on that dialog + plus the session interval. If UA wishes to continue with the session + beyond the session expiration, it MUST generate a refresh before the + session expiration. It is RECOMMENDED that this refresh be sent once + half the session interval has elapsed. Additional procedures for + this refresh are described in Section 10. + +10. Performing Refreshes + + The side generating a refresh does so according to the UAC procedures + defined in Section 7. Note that only a 2xx response to a session + refresh request extends the session expiration. This means that a UA + could attempt a refresh and receive a 422 response with a Min-SE + header field that contains a value much larger than the current + session interval. The UA will still have to send a session refresh + request before the session expiration (which has not changed), even + though this request will contain a value of the Session-Expires that + is much larger than the current session interval. + + If the session refresh request transaction times out or generates a + 408 or 481 response, then the UAC sends a BYE request as per Section + 12.2.1.2 of RFC 3261 [2]. If the session refresh request does not + generate a 2xx response (and, as a result, the session is not + refreshed), and a response other than 408 or 481 is received, the UAC + + + +Donovan & Rosenberg Standards Track [Page 17] + +RFC 4028 Session Timer April 2005 + + + SHOULD follow the rules specific to that response code and retry if + possible. For example, if the response is a 401, the UAC would retry + the request with new credentials. However, the UAC SHOULD NOT + continuously retry the request if the server indicates the same error + response. + + Similarly, if the side not performing refreshes does not receive a + session refresh request before the session expiration, it SHOULD send + a BYE to terminate the session, slightly before the session + expiration. The minimum of 32 seconds and one third of the session + interval is RECOMMENDED. + + Firewalls and NAT ALGs may be very unforgiving about allowing SIP + traffic to pass after the expiration time of the session. This is + why the BYE should be sent before the expiration. + +11. Security Considerations + + The session timer introduces the capability of a proxy or UA element + to force compliant UAs to send refreshes at a rate of the element's + choosing. This introduces the possibility of denial-of-service + attacks with significant amplification properties. These attacks can + be launched from 'outsiders' (elements that attempt to modify + messages in transit) or by 'insiders' (elements that are legitimately + in the request path but are intent on doing harm). Fortunately, both + cases are adequately handled by this specification. + +11.1. Inside Attacks + + This introduces the possibility of rogue proxies or UAs introducing + denial-of-service attacks. However, the mechanisms in this + specification prevent that from happening. + + First, consider the case of a rogue UAC that wishes to force a UAS to + generate refreshes at a rapid rate. To do so, it inserts a + Session-Expires header field into an INVITE with a low duration and a + refresher parameter equal to uas. Assume it places a Supported + header field into the request. The UAS or any proxy that objects to + this low timer will reject the request with a 422, thereby preventing + the attack. If no Supported header field was present, the proxies + will insert a Min-SE header field into the request before forwarding + it. As a result, the UAS will not choose a session timer lower than + the minimum allowed by all elements on the path. This too prevents + the attack. + + Next, consider the case of a rogue UAS that wishes to force a UAC to + generate refreshes at a rapid rate. In that case, the UAC has to + support session timer. The initial INVITE arrives at the rogue UAS, + + + +Donovan & Rosenberg Standards Track [Page 18] + +RFC 4028 Session Timer April 2005 + + + which returns a 2xx with a very small session interval. The UAC uses + this timer and quickly sends a refresh. Section 7.4 requires that + the UAC copy the current session interval into the Session-Expires + header field in the request. This enables the proxies to see the + current value. The proxies will reject this request and provide a + Min-SE with a higher minimum, which the UAC will then use. Note, + that if the proxies did not reject the request, but rather proxied + the request with a Min-SE header field, an attack would still be + possible. The UAS could discard this header field in a 2xx response + and force the UAC to continue to generate rapid requests. + + In a similar fashion, a rogue proxy cannot force either the UAC or + UAS to generate refreshes unless the proxy remains on the signaling + path and sees every request and response. + +11.2. Outside Attacks + + An element that can observe and modify a request or response in + transit can force rapid session refreshes. To prevent this, requests + and responses have to be protected by message integrity. Since the + session timer header fields are not end-to-end and are manipulated by + proxies, the SIP S/MIME capabilities are not suitable for this task. + Rather, integrity has to be protected by using hop-by-hop mechanisms. + As a result, it is RECOMMENDED that an element send a request with a + Session-Expires header field or a Supported header field with the + value 'timer' by using TLS. As adequate protection is obtained only + if security is applied on each hop, it is RECOMMENDED that the SIPS + URI scheme be used in conjunction with this extension. This means + that proxies that record-route and request session timer SHOULD + record-route with a SIPS URI. A UA that inserts a Session-Expires + header into a request or response SHOULD include a Contact URI that + is a SIPS URI. + +12. IANA Considerations + + This extension defines two new header fields, a new response code, + and a new option tag. SIP [2] defines IANA procedures for + registering these. + +12.1. IANA Registration of Min-SE and Session-Expires Header Fields + + The following is the registration for the Min-SE header field: + + RFC Number: RFC 4028 + Header Name: Min-SE + Compact Form: none + + + + + +Donovan & Rosenberg Standards Track [Page 19] + +RFC 4028 Session Timer April 2005 + + + The following is the registration for the Session-Expires header + field: + + RFC Number: RFC 4028 + Header Name: Session-Expires + Compact Form: x + +12.2. IANA Registration of the 422 (Session Interval Too Small) + Response Code + + The following is the registration for the 422 (Session Interval Too + Small) response code: + + Response Code: 422 + Default Reason Phrase: Session Interval Too Small + RFC Number: RFC 4028 + +12.3. IANA Registration of the 'timer' Option Tag + + The following is the registration for the 'timer' option tag: + + Name: timer + Description: This option tag is for support of the session timer + extension. Inclusion in a Supported header field in a request or + response indicates that the UA can perform refreshes according to + that specification. Inclusion in a Require header in a request + means that the UAS must understand the session timer extension to + process the request. Inclusion in a Require header field in a + response indicates that the UAC must look for the Session-Expires + header field in the response and process it accordingly. + +13. Example Call Flow + + Example Session Timer Flow + + Alice Proxy P1 Proxy P2 Bob + |(1) INVITE | | | + |SE: 50 | | | + |----------->| | | + |(2) 422 | | | + |MSE: 3600 | | | + |<-----------| | | + |(3) ACK | | | + |----------->| | | + |(4) INVITE | | | + |SE:3600 | | | + |MSE:3600 | | | + |----------->| | | + + + +Donovan & Rosenberg Standards Track [Page 20] + +RFC 4028 Session Timer April 2005 + + + | |(5) INVITE | | + | |SE:3600 | | + | |MSE:3600 | | + | |----------->| | + | |(6) 422 | | + | |MSE:4000 | | + | |<-----------| | + | |(7) ACK | | + | |----------->| | + |(8) 422 | | | + |MSE:4000 | | | + |<-----------| | | + |(9) ACK | | | + |----------->| | | + |(10) INVITE | | | + |SE:4000 | | | + |MSE:4000 | | | + |----------->| | | + | |(11) INVITE | | + | |SE:4000 | | + | |MSE:4000 | | + | |----------->| | + | | |(12) INVITE | + | | |SE:4000 | + | | |MSE:4000 | + | | |----------->| + | | |(13) 200 OK | + | | |SE:4000 | + | | |<-----------| + | |(14) 200 OK | | + | |SE:4000 | | + | |<-----------| | + |(15) 200 OK | | | + |SE:4000 | | | + |<-----------| | | + |(16) ACK | | | + |----------->| | | + | |(17) ACK | | + | |------------------------>| + |(18) UPDATE | | | + |SE:4000 | | | + |----------->| | | + | |(19) UPDATE | | + | |SE:4000 | | + | |------------------------>| + | |(20) 200 OK | | + | |SE:4000 | | + | |<------------------------| + + + +Donovan & Rosenberg Standards Track [Page 21] + +RFC 4028 Session Timer April 2005 + + + |(21) 200 OK | | | + |SE:4000 | | | + |<-----------| | | + | |(22) BYE | | + | |<------------------------| + |(23) BYE | | | + |<-----------| | | + | |(24) 408 | | + | |------------------------>| + + Figure 1: Example Session Timer Flow + + Figure 1 gives an example of a call flow that makes use of the + session timer. In this example, both the UAC and UAS support the + session timer extension. The initial INVITE request generated by the + UAC, Alice (message 1), might look like this: + + INVITE sips:bob@biloxi.example.com SIP/2.0 + Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 + Supported: timer + Session-Expires: 50 + Max-Forwards: 70 + To: Bob + From: Alice ;tag=1928301774 + Call-ID: a84b4c76e66710 + CSeq: 314159 INVITE + Contact: + Content-Type: application/sdp + Content-Length: 142 + + (Alice's SDP not shown) + + This request indicates that Alice supports the session timer, and is + requesting session refreshes every 50 seconds. This arrives at the + first proxy, P1. This session interval is below the minimum allowed + value of 3600. So P1 rejects the request with a 422 (message 2): + + SIP/2.0 422 Session Interval Too Small + Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 + ;received=192.0.2.1 + Min-SE: 3600 + To: Bob ;tag=9a8kz + From: Alice ;tag=1928301774 + Call-ID: a84b4c76e66710 + CSeq: 314159 INVITE + + + + + + +Donovan & Rosenberg Standards Track [Page 22] + +RFC 4028 Session Timer April 2005 + + + This response contains a Min-SE header field with the value 3600. + Alice then retries the request. This time, the request contains a + Min-SE header, as Alice has received a 422 for other INVITE requests + with the same Call-ID. The new request (message 4) might look like + this: + + INVITE sips:bob@biloxi.example.com SIP/2.0 + Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 + Supported: timer + Session-Expires: 3600 + Min-SE: 3600 + Max-Forwards: 70 + To: Bob + From: Alice ;tag=1928301774 + Call-ID: a84b4c76e66710 + CSeq: 314160 INVITE + Contact: + Content-Type: application/sdp + Content-Length: 142 + + (Alice's SDP not shown) + + Proxy P1 record-routes. Since the session interval is now acceptable + to it, it forwards the request to P2 (message 5). However, the + session interval is below its minimum configured amount of 4000. So + it rejects the request with a 422 response code (message 6) and + includes a Min-SE header field with the value of 4000. Once more, + Alice retries the INVITE. This time, the Min-SE header field in her + INVITE is the maximum of all Min-SE she has received (3600 and 4000). + Message 10 might look like this: + + INVITE sips:bob@biloxi.example.com SIP/2.0 + Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10 + Supported: timer + Session-Expires: 4000 + Min-SE: 4000 + Max-Forwards: 70 + To: Bob + From: Alice ;tag=1928301774 + Call-ID: a84b4c76e66710 + CSeq: 314161 INVITE + Contact: + Content-Type: application/sdp + Content-Length: 142 + + (Alice's SDP not shown) + + + + + +Donovan & Rosenberg Standards Track [Page 23] + +RFC 4028 Session Timer April 2005 + + + P1 record-routes once again, but P2 does not (this wouldn't normally + happen; presumably, if it asked for session timer, it would + record-route the subsequent request). The UAS receives the request. + It copies the Session-Expires header from the request to the response + and adds a refresher parameter with value 'uac'. This 200 OK is + forwarded back to Alice. The response she receives (message 15) + might look like this: + + SIP/2.0 200 OK + Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10 + ;received=192.0.2.1 + Require: timer + Supported: timer + Record-Route: sips:p1.atlanta.example.com;lr + Session-Expires: 4000;refresher=uac + To: Bob ;tag=9as888nd + From: Alice ;tag=1928301774 + Call-ID: a84b4c76e66710 + CSeq: 314161 INVITE + Contact: + Content-Type: application/sdp + Content-Length: 142 + + (Bob's SDP not shown) + + Alice generates an ACK (message 16), which is routed through P1 and + then to Bob. Since Alice is the refresher, around 2000 seconds later + Alice sends an UPDATE request to refresh the session. Because this + request is part of an established dialog and Alice has not received + any 422 responses or requests on that dialog, there is no Min-SE + header field in her request (message 18): + + UPDATE sips:bob@192.0.2.4 SIP/2.0 + Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12 + Route: sips:p1.atlanta.example.com;lr + Supported: timer + Session-Expires: 4000;refresher=uac + Max-Forwards: 70 + To: Bob ;tag=9as888nd + From: Alice ;tag=1928301774 + Call-ID: a84b4c76e66710 + CSeq: 314162 UPDATE + Contact: + + + + + + + + +Donovan & Rosenberg Standards Track [Page 24] + +RFC 4028 Session Timer April 2005 + + + This is forwarded through P1 to Bob. Bob generates a 200 OK, copying + the Session-Expires header field into the response. This is + forwarded through P1 and arrives at Alice. The response she receives + (message 21) might look like this: + + SIP/2.0 200 OK + Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12 + ;received=192.0.2.1 + Require: timer + Session-Expires: 4000;refresher=uac + To: Bob ;tag=9as888nd + From: Alice ;tag=1928301774 + Call-ID: a84b4c76e66710 + CSeq: 314162 UPDATE + Contact: + + Shortly afterward, Alice's UA crashes. As a result, she never sends + a session refresh request. 3968 seconds later, Bob times out and + sends a BYE request (message 22). This is sent to P1. P1 attempts + to deliver it but fails (because Alice's UA has crashed). P1 then + returns a 408 (Request Timeout) to Bob. + +14. Acknowledgements + + The authors wish to thank Brett Tate for his contributions to this + work. Brian Rosen completed the editing of the document. + +15. References + +15.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] 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. + + [3] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE + Method", RFC 3311, October 2002. + + [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with + Session Description Protocol (SDP)", RFC 3264, June 2002. + + + + + + + + +Donovan & Rosenberg Standards Track [Page 25] + +RFC 4028 Session Timer April 2005 + + +15.2. Informative References + + [5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, + "RTP: A Transport Protocol for Real-Time Applications", STD 64, + RFC 3550, July 2003. + + [6] Srisuresh, P. and M. Holdrege, "IP Network Address Translator + (NAT) Terminology and Considerations", RFC 2663, August 1999. + + [7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional + Responses in Session Initiation Protocol (SIP)", RFC 3262, June + 2002. + + [8] Roach, A., "Session Initiation Protocol (SIP)-Specific Event + Notification", RFC 3265, June 2002. + +Authors' Addresses + + Steve Donovan + Cisco Systems, Inc. + 2200 E. President George Bush Turnpike + Richardson, Texas 75082 + US + + EMail: srd@cisco.com + + + Jonathan Rosenberg + Cisco Systems, Inc. + 600 Lanidex Plaza + Parsippany, NJ 07054 + US + + EMail: jdrosen@cisco.com + + + + + + + + + + + + + + + + + +Donovan & Rosenberg Standards Track [Page 26] + +RFC 4028 Session Timer April 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + 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. + + 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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Donovan & Rosenberg Standards Track [Page 27] + -- cgit v1.2.3