rfc4028.htm

RFC4028,session timer的标准文档

   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



<SPAN class=grey>Donovan &amp; Rosenberg         Standards Track                    [Page 16]</SPAN>
<A class=invisible id=page-17 href="#page-17" name=page-17><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="./rfc4028">RFC 4028</A>                     Session Timer                    April 2005</SPAN>


   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 <A href="#section-10">Section 10</A>.

<SPAN class=h2><A name=section-10>10</A>.  Performing Refreshes</SPAN>

   The side generating a refresh does so according to the UAC procedures
   defined in <A href="#section-7">Section 7</A>.  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 <A href="./rfc3261">RFC 3261</A> [<A title='"SIP: Session Initiation Protocol"' href="#ref-2">2</A>].  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



<SPAN class=grey>Donovan &amp; Rosenberg         Standards Track                    [Page 17]</SPAN>
<A class=invisible id=page-18 href="#page-18" name=page-18><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="./rfc4028">RFC 4028</A>                     Session Timer                    April 2005</SPAN>


   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.

<SPAN class=h2><A name=section-11>11</A>.  Security Considerations</SPAN>

   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.

<SPAN class=h3><A name=section-11.1>11.1</A>.  Inside Attacks</SPAN>

   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,



<SPAN class=grey>Donovan &amp; Rosenberg         Standards Track                    [Page 18]</SPAN>
<A class=invisible id=page-19 href="#page-19" name=page-19><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="./rfc4028">RFC 4028</A>                     Session Timer                    April 2005</SPAN>


   which returns a 2xx with a very small session interval.  The UAC uses
   this timer and quickly sends a refresh.  <A href="#section-7.4">Section 7.4</A> 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.

<SPAN class=h3><A name=section-11.2>11.2</A>.  Outside Attacks</SPAN>

   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.

<SPAN class=h2><A name=section-12>12</A>.  IANA Considerations</SPAN>

   This extension defines two new header fields, a new response code,
   and a new option tag.  SIP [<A title='"SIP: Session Initiation Protocol"' href="#ref-2">2</A>] defines IANA procedures for
   registering these.

<SPAN class=h3><A name=section-12.1>12.1</A>.  IANA Registration of Min-SE and Session-Expires Header Fields</SPAN>

   The following is the registration for the Min-SE header field:

   RFC Number: <A href="./rfc4028">RFC 4028</A>
   Header Name: Min-SE
   Compact Form: none





<SPAN class=grey>Donovan &amp; Rosenberg         Standards Track                    [Page 19]</SPAN>
<A class=invisible id=page-20 href="#page-20" name=page-20><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="./rfc4028">RFC 4028</A>                     Session Timer                    April 2005</SPAN>


   The following is the registration for the Session-Expires header
   field:

   RFC Number: <A href="./rfc4028">RFC 4028</A>
   Header Name: Session-Expires
   Compact Form: x

<SPAN class=h3><A name=section-12.2>12.2</A>.  IANA Registration of the 422 (Session Interval Too Small)</SPAN>
       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: <A href="./rfc4028">RFC 4028</A>

<SPAN class=h3><A name=section-12.3>12.3</A>.  IANA Registration of the 'timer' Option Tag</SPAN>

   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.

<SPAN class=h2><A name=section-13>13</A>.  Example Call Flow</SPAN>

   Example Session Timer Flow

       Alice      Proxy P1     Proxy P2        Bob
         |(1) INVITE  |            |            |
         |SE: 50      |            |            |
         |-----------&gt;|            |            |
         |(2) 422     |            |            |
         |MSE: 3600   |            |            |
         |&lt;-----------|