Internet DRAFT - draft-hilt-sipping-policy-scenarios

draft-hilt-sipping-policy-scenarios





Session Initiation Proposal                                      V. Hilt
Investigation Working Group                Bell Labs/Lucent Technologies
Internet-Draft                                              G. Camarillo
Expires: January 8, 2005                                        Ericsson
                                                           July 10, 2004



           Evaluating Scenarios for Session-specific Policies
                 draft-hilt-sipping-policy-scenarios-00


Status of this Memo


   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."


   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


   This Internet-Draft will expire on January 8, 2005.


Copyright Notice


   Copyright (C) The Internet Society (2004). All Rights Reserved.


Abstract


   This draft describes detailed call flows for different use cases of
   session-specific policies. It compares the two approaches that are
   currently being discussed for session-specific policies, namely the
   piggyback model and the separate channel model.









Hilt & Camarillo        Expires January 8, 2005                 [Page 1]
Internet-Draft          Session Policy Scenarios               July 2004



Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     4.1   NAT Traversal  . . . . . . . . . . . . . . . . . . . . . .  4
       4.1.1   Piggyback Model  . . . . . . . . . . . . . . . . . . .  4
       4.1.2   Separate Channel Model . . . . . . . . . . . . . . . .  9
     4.2   Codec Selection  . . . . . . . . . . . . . . . . . . . . . 12
   5.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     5.1   Disclosure of Session Descriptions and Policies  . . . . . 13
     5.2   UA Support of Policies . . . . . . . . . . . . . . . . . . 13
     5.3   Re-Use of Document Formats and Mechanisms  . . . . . . . . 13
     5.4   Asynchronous Policies  . . . . . . . . . . . . . . . . . . 14
     5.5   Separation of Tasks  . . . . . . . . . . . . . . . . . . . 14
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   A.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
       Intellectual Property and Copyright Statements . . . . . . . . 16
































Hilt & Camarillo        Expires January 8, 2005                 [Page 2]
Internet-Draft          Session Policy Scenarios               July 2004



1.  Introduction


   The concept of session-specific SIP session policies [3] has been
   around for some time. However, it has proven that the mechanisms for
   establishing session-specific policies are non-trivial and most
   likely require to sacrifice some of the requirements defined in [5].


   In this draft, we compare two approaches that have been proposed for
   session-specific policies: the piggyback model and the separate
   channel model. We analyze detailed call flows of use cases for both
   models and discuss advantages and drawbacks of each model.


   The main purpose of this draft is to spark the discussion about the
   two models and to come to a conclusion on which if the models is the
   most appropriate approach for session-specific policies.


2.  Terminology


   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14, [1] and indicate requirement levels for
   compliant implementations.


3.  Scenario


   All use cases in the subsequent sections are based on the following
   scenario (see Figure 1). The user agent UA A is registered at proxy P
   A, which is responsible for domain A. UA B is registered at P B in
   domain B. Both domains A and B are separate and they are connected
   through a transit network.


   It is assumed that user agent and proxy of each domain have a
   relationship (e.g. UA A is a customer of provider running domain A).
   It is also assumed that the entities in different domains do not
   necessarily have a relationship. This corresponds to a scenario where
   a customer of one provider is establishing a session with a customer
   of another provider. As a consequence, entities in one domain can't
   make any assumptions about the capabilities of entities in the other
   domain. In particular, it can't be assumed that session policies are
   supported in the other domain. Additionally, it is assumed that
   entities in one domain are not willing to disclose network internals
   such as session policies to the other domain.









Hilt & Camarillo        Expires January 8, 2005                 [Page 3]
Internet-Draft          Session Policy Scenarios               July 2004



                   :         :
             +---+ :         :  +---+
           /-|P A|-:---------:--|P B|-\
    +----+/  +---+ :         :  +---+  \+----+
    |UA A|         :         :          |UA B|
    +----+         :         :          +----+
                   :         :
       Domain A      Transit       Domain B
                     Network



                                Figure 1



4.  Use Cases


4.1  NAT Traversal


   In this scenario, each domain is connected to the public Internet
   through a NAT. UA A and UA B have local, non-routable addresses. The
   proxies P A and P B implement MIDCOM [6] agents an control an
   associated NAT that connects their domain to the Internet.


   Session policies are needed to accomplish the following tasks for NAT
   traversal:


   o  Enable proxies to examine the media addresses and ports in the
      session description created by its associated UA (can either be an
      offer or an answer). This information is needed to configure NAT
      rules for incoming media traffic.
   o  Enable proxies to modify the media addresses and ports in the
      session description created by its associated UA (offer or
      answer). The modification is needed to replace the local addresses
      with globally routable addresses at which the associated UA is
      reachable from  outside.
   o  Enable a proxy to examine the media addresses and ports in the
      session description created by the remote UA (offer or answer).
      This information is needed to configure NAT rules for outgoing
      media traffic.


4.1.1  Piggyback Model


   In the piggyback model, session policies are piggybacked on the SIP
   messages used for the corresponding SDP offer/answer exchange.


4.1.1.1  Offer in Request - Alternative 1


   The call flow in Figure 2 describes the piggyback model for INVITE




Hilt & Camarillo        Expires January 8, 2005                 [Page 4]
Internet-Draft          Session Policy Scenarios               July 2004



   requests carrying a session description offer. This alternative is
   based on encryption to protect MIOs and MFOs from being inspected by
   unauthorized network entities (e.g. in the transit network). It
   corresponds to the piggyback model that has been discussed so far
   (e.g. in [3])


   It is important to note that this alternative still requires that the
   UAs on both sides support session-specific policies, even if policies
   are only used in one domain. In other words, to enable the use of
   policies between UA A and P A in domain A, UA B in domain B also
   needs to support policies, even if policies are not used in this
   domain. Furthermore, encryption can only protect policies from being
   inspected in the transit network. Entities in both domains must be
   able to inspect the policies of the other domain.



    UA A             P A              P B              UA B
     |                |                |                |
     | INVITE offer   |                |                |
     |--------------->|                |                | (1)
     | 488            |                |                |
     | +DiscloseInfoA |                |                |
     |<---------------|                |                | (2)
     | ACK            |                |                |
     |--------------->|                |                |
     |                |                |                |
     | INVITE offer   | INVITE offer   |                |
     | +[MIOAoffer]A  | +[MIOAoffer]A  |                |
     |                | +[MFOAoffer]B  |                |
     |--------------->|--------------->|                | (3)
     | 488            | 488            |                |
     | +DiscloseInfoB | +DiscloseInfoB |                |
     |<---------------|<---------------|                | (4)
     | ACK            | ACK            |                |
     |--------------->|--------------->|                |
     |                |                |                |
     | INVITE offer   | INVITE offer   | INVITE offer   |
     | +[MIOAoffer]AB | +[MIOAoffer]AB | +[MIOAoffer]AB |
     |                | +[MFOAoffer]B  | +[MFOAoffer]B  |
     |                |                | +DiscloseInfoB |
     |--------------->|--------------->|--------------->| (5)
     |                |                |                |
     | 183 answer     | 183 answer     | 183 answer     |
     | +[MIOBanswer]B | +[MIOBanswer]B | +[MIOBanswer]B |
     | +[MFOBanswer]A | +[MFOBanswer]A |                |
     |<---------------|<---------------|<---------------| (6)
     |                |                |                |
     | PRACK          | PRACK          | PRACK          |




Hilt & Camarillo        Expires January 8, 2005                 [Page 5]
Internet-Draft          Session Policy Scenarios               July 2004



     | +[MIOAanswer]A | +[MIOAanswer]A | +[MIOAanswer]A |
     |--------------->|--------------->|--------------->| (7)
     | OK             | OK             | OK             |
     |<---------------|<---------------|<---------------|
     |                |                |                |
     | OK             | OK             | OK             |
     |<---------------|<---------------|<---------------|
     |                |                |                |
     | ACK                                              |
     |------------------------------------------------->|
     |                                                  |



                                Figure 2


   Steps (1) and (2) are needed if P A detects that UA A does not
   disclose the required aspects of its session description offer in a
   Media Interface Object A (MIOAoffer). In this case, P A returns a 488
   response that requests the  disclosure of these aspects. This steps
   could be avoided, for example, by providing information about what to
   disclose as part of the device configuration [4].


   In step (3) UA A creates Media Interface Object A (MIOAoffer) that
   discloses the IP addresses and ports it has used in the offer. UA A
   encrypts MIOAoffer with a key known to P A ([MIOAoffer]A). P A can
   now perform its MIDCOM functionalities based on the data in MIOAoffer
   and creates a Media Filter Object for MIOAoffer (MFOAoffer), which
   contains the external addresses and ports UA B must use to reach UA
   A. P A encrypts MFOAoffer with a key known to UA B.


   In step (4) P B returns a 488 response and asks UA A to disclose the
   addresses and ports used in the offer. It also asks P A to disclose
   all policies that affect the addresses and ports in the offer, since
   these are the addresses and ports that will later be used in the
   session.


   Step (5) is analogous to step (3) except that MIOAoffer and MFOAoffer
   are now encrypted with a keys known to P B and UA B. Finally, P B
   asks UA B to disclose the addresses and ports it is going to use in
   the answer.


   In step (6) UA B has accepted the policies contained in MFOAoffer. It
   creates a 183 response with its session description answer and a
   MIOBanswer containing the local IP addresses and ports. UA B encrypts
   MIOBanswer with a key known to P B. The use of a 183 response instead
   of a 200 OK later enables UA A to cancel the INVITE transaction if it
   decides not to accept the requested policies before the INVITE
   transaction is completed.




Hilt & Camarillo        Expires January 8, 2005                 [Page 6]
Internet-Draft          Session Policy Scenarios               July 2004



   P B examines the addresses and ports in MIOBanswer and inserts
   MFOBanswer containing the external addresses and ports to be used
   with the session description answer. It encrypts MFOBanswer with a
   key known to UA A.


   In step (7) UA A accepts the policies in MFOBanswer and creates a
   PRACK. It inserts a MIOAanswer, which contains the addresses and
   ports it is using to send media to UA B. UA A encrypts MIOAanswer
   with a key known to P A. Since P A has no policies for the answer, no
   additional MFOs are needed.


4.1.1.2  Offer in Request - Alternative 2


   The call flow in Figure 3 also piggybacks policy information on
   messages exchanged within a SIP INVITE transaction. In this call
   flow, these messages are used to exchange policies between UA and
   proxy. The flow ensures that policy information does not leave the
   local domain by rejecting messages and removing policy headers.



    UA A             P A              P B              UA B
     |                |                |                |
     | INVITE offer   |                |                |
     |--------------->|                |                | (1)
     | 488            |                |                |
     | +DiscloseInfoA |                |                |
     |<---------------|                |                | (2)
     | ACK            |                |                |
     |--------------->|                |                |
     |                |                |                |
     | INVITE offer   |                |                |
     | +MIOAoffer     |                |                |
     |--------------->|                |                | (3)
     | 488            |                |                |
     | +MFOAoffer     |                |                |
     |<---------------|                |                | (4)
     | ACK            |                |                |
     |--------------->|                |                |
     |                |                |                |
     | INVITE offer   | INVITE offer   | INVITE offer   |
     |                |                | +DiscloseInfoB |
     |--------------->|--------------->|--------------->| (5)
     |                |                |                |
     | 183 answer     | 183 answer     | 183 answer     |
     |                |                | +MIOBoffer     |
     |                |                | +MIOBanswer    |
     |<---------------|<---------------|<---------------| (6)
     |                |                |                |




Hilt & Camarillo        Expires January 8, 2005                 [Page 7]
Internet-Draft          Session Policy Scenarios               July 2004



     | PRACK          | PRACK          | PRACK          |
     | +MIOAanswer    |                |                |
     |                |                | +MFOBanswer    |
     |--------------->|--------------->|--------------->| (7)
     | OK             | OK             | OK             |
     |<---------------|<---------------|<---------------|
     |                |                |                |
     | UPDATE offer   | UPDATE offer   | UPDATE offer   |
     |<---------------|<---------------|<---------------| (8)
     |                |                |                |
     | OK answer      | OK answer      | OK answer      |
     | +MIOAanswer    |                |                |
     |--------------->|--------------->|--------------->| (9)
     |                |                |                |
     | OK             | OK             | OK             |
     |<---------------|<---------------|<---------------|
     |                |                |                |
     | ACK                                              |
     |------------------------------------------------->|
     |                                                  |



                                Figure 3


   The basic idea of exchanging MIOs and MFOs is the same as in the
   above flow. Steps (1) - (3) are identical. In step (4) P A returns a
   MFOAoffer containing the modified addresses and ports for the offer
   to UA A. UA A can now apply these policies and create a new offer in
   step (5).


   In step (5) P B also requests the disclosure of the addresses used in
   the offer and answer and receives them from UA B in step (6). Since
   UA B has not received policies from P B yet, the answer in step (6)
   is a dummy answer that needs to be updated later.


   In step (7) UA A creates a PRACK containing a MIOAanswer which is
   still based on the dummy answer. P B uses this PRACK message to
   transmit the addresses and ports it wants UA B to use in its session
   description to UA B. To make these addresses and ports known to UA A,
   UA B creates an new offer and sends an UPDATE in step (8) to which UA
   A responds in step (9). UA A also creates a new MIOAanswer for P A
   that is now based on the actual session description used in the
   session.


4.1.1.3  Offer in Response


   The piggyback model call flows for INVITEs that carry the session
   description offer in the response are analogous to the above call




Hilt & Camarillo        Expires January 8, 2005                 [Page 8]
Internet-Draft          Session Policy Scenarios               July 2004



   flows. However, these flow are generally more complex that the flows
   described above for the offer in request scenario.


4.1.2  Separate Channel Model


   The idea behind the Separate Channel Model is that user agents
   retrieve session-specific policies through a separate channel before
   they create the session description offer/answer. The channel can be
   implemented in different ways, based on SIP or on another protocol.
   In this document we simply make the assumption that this channel
   enables a UA to send a MIO to the policy server and to retrieve a MFO
   as a response.


4.1.2.1  Offer in Request


   The call flow in Figure 4 depicts the separate channel model for
   INVITE requests carrying a session description offer. PS A and PS B
   are the policy servers in the respective domains. They can be
   co-located with the proxies P A and P B but do not have to be.



    UA A             P A              P B             UA B
     |                |                |                |
     | INVITE offer   |                |                |
     |--------------->|                |                | (1)
     | 488            |                |                |
     | + DiscloseInfA |                |                |
     |<---------------|                |                | (2)
     | ACK            |                |                |
     |--------------->|                |                |
     |                | PS A           |                |
     | Sep.Channel       |             |                |
     | + MIOAoffer       |             |                |
     |------------------>|             |                | (3)
     | Sep.Channel       |             |                |
     | + MFOAoffer       |             |                |
     |<------------------|             |                | (4)
     |                   |             |                |
     |                |                |                |
     | INVITE offer   | INVITE offer   | INVITE offer   |
     |                |                | + DiscloseInfB |
     |--------------->|--------------->|--------------->| (5)
     |                |                |                |
     |                |           PS B |                |
     |                |             |                   |
     |                |             | Sep.Channel       |
     |                |             | + MIOBoffer       |
     |                |             | + MIOBanswer      |




Hilt & Camarillo        Expires January 8, 2005                 [Page 9]
Internet-Draft          Session Policy Scenarios               July 2004



     |                |             |<------------------| (6)
     |                |             | Sep.Channel       |
     |                |             | + MFOBanswer      |
     |                |             |------------------>| (7)
     |                |             |                   |
     |                |                |                |
     | OK answer      | OK answer      | OK answer      |
     |<---------------|<---------------|<---------------| (8)
     | ACK                                              |
     |------------------------------------------------->|
     |                |                |                |
     | Sep.Channel       |             |                |
     | + MIOAanswer      |             |                |
     |------------------>|             |                | (9)
     |                   |             |                |
     |                |                |                |



                                Figure 4


   Steps (1) and (2) are needed if P A detects that UA A has not
   requested policies for the current session before creating the SDP
   offer. In this case, P A returns a 488 response that contains the
   address to which UA A should establish a channel to and information
   about what should be disclosed in an MIO. These steps can be avoided,
   for example, by providing the information about what to disclosure to
   where as part of the device configuration.


   In step (3) UA A establishes a channel to PS A and submits a
   MIOAoffer in which it reveals the addresses and ports it is going to
   use in the offer. PS A uses this information in its function as
   MIDCOM agent and returns the addresses and ports UA A should include
   in its offer in an MFOAoffer in step (4).


   In step (5) UA A decides to accept the policies in MFOAoffer and
   creates the offer using the given addresses and ports. P B inserts
   disclosure information for UA B into this message.


   Before creating an answer, UA B retrieves the policies that apply to
   this session by establishing a channel to its policy server in step
   (6). It submits the addresses and ports from the offer in MIOBoffer
   and the addresses and ports it is going to use in its answer in
   MIOBanswer. PS B returns the addresses and ports to be used in the
   answer in MFOBanswer in step (7). If UA B decides to accept these
   policies, it creates an answer in step (8). If not, UA B can return a
   final response rejecting the INVITE.


   In step (9), UA A submits MIOAanswer to the local policy server




Hilt & Camarillo        Expires January 8, 2005                [Page 10]
Internet-Draft          Session Policy Scenarios               July 2004



   disclosing the addresses and ports received in the answer from UA B.


4.1.2.2  Offer in Response


   The call flow for an INVITE carrying the offer in the response is
   depicted in Figure 5. In contrast to call flow Figure 4, UA A has to
   wait until it receives an offer from UA B before it can retrieve the
   policies for the current session.



    UA A            P/M A            P/M B             UA B
     |                |                |                |
     | INVITE         | INVITE         | INVITE         |
     |                |                | + DiscloseInfB |
     |--------------->|--------------->|--------------->| (1)
     |                |                |                |
     |                |           PS B |                |
     |                |             | Sep.Channel       |
     |                |             | + MIOBoffer       |
     |                |             |<------------------| (2)
     |                |             | Sep.Chanel        |
     |                |             | + MFOBoffer       |
     |                |             |------------------>| (3)
     |                |             |                   |
     |                |                |                |
     | 183 offer      | 183 offer      | 183 offer      |
     | + DiscloseInfA |                |                |
     |<---------------|<---------------|<---------------| (4)
     | PRACK answer                                     |
     |------------------------------------------------->| (5)
     | OK                                               |
     |<-------------------------------------------------|
     |                |                |                |
     |                | PS A           |                |
     | Sep.Channel       |             |                |
     | + MIOAoffer       |             |                |
     | + MIOAanswer      |             |                |
     |------------------>|             |                | (6)
     | Sep.Channel       |             |                |
     | + MFOAanswer      |             |                |
     |<------------------|             |                | (7)
     |                   |             |                |
     |                |                |                |
     | UPDATE offer'                                    |
     |------------------------------------------------->| (8)
     | OK answer'                                       |
     |<-------------------------------------------------|
     |                |                |                |




Hilt & Camarillo        Expires January 8, 2005                [Page 11]
Internet-Draft          Session Policy Scenarios               July 2004



     |                |             |                   |
     |                |             | Sep.Channel       |
     |                |             | + MIOBanswer      |
     |                |             |<------------------| (9)
     |                |             |                   |
     |                |                |                |
     | OK             | OK             | OK             |
     |<---------------|<---------------|<---------------|
     | ACK                                              |
     |------------------------------------------------->|
     |                                                  |



                                Figure 5


   After receiving the 183 response in step (4), UA A must respond
   immediately with a PRACK to avoid the expiration of timer T1 in UA B
   and the retransmission of the 183. UA A therefore creates a PRACK
   with an answer that does not yet consider session-specific policies.
   It then retrieves the policies for the current session in steps (6)
   and (7) in which it gets the external addresses and ports from PS A
   in MFOAanswer. It creates a new offer and sends it to UA B in the
   UPDATE shown in step (7).


      ISSUE: If it can be assumed that UA A and the policy server are
      located in the same network, there might be enough time for UA A
      to retrieve policies before generating the PRACK. The sequence of
      steps would then be (1)-(3),(5)-(6),(4) without a need for the
      UPDATE in step (7). Is this a reasonable assumption?


4.2  Codec Selection


   In this scenario, session-specific policies are used to limit the set
   of codecs a UA can use. By using session-specific policies, a network
   provider does not need to reveal the list of allowed codecs to the
   UA. Instead it can limit the use of certain codecs only if endpoints
   announce them in an SDP description.


   Session policies are needed to accomplish the following tasks for
   codec selection:


   o  Enable a proxy to examine the codecs listed in the session
      description offer (independent of whether the offer was created by
      the local or the remote UA).
   o  Enable proxies to remove codecs from the offer (independent of
      whether the offer was created by the local or the remote UA).


   The call flows for both models are analogous to the NAT scenario,




Hilt & Camarillo        Expires January 8, 2005                [Page 12]
Internet-Draft          Session Policy Scenarios               July 2004



   with the difference that the policy servers do not not provide
   policies for the answer. Instead, they both provide policies for the
   session description offer. Also, MIOs contain lists of codecs and
   MFOs identify those codecs that should not be used.


5.  Discussion


5.1  Disclosure of Session Descriptions and Policies


   In the piggyback model (alternative 1), all MIOs and MFOs travel
   through the network. End-to-middle and middle-to-end encryption can
   be used to prevent unauthorized network entities from examining them.
   However, even with encryption, UAs need to disclose MIOs to all
   policy-enabled proxies even if they are located in remote networks.
   Moreover, proxies must disclose their policies to UAs in remote
   networks and to other proxies that are interested in examining or
   modifying the same aspect of a session description.


   In the piggyback model (alternative 2), the MIOs and MFOs are
   piggybacked on messaged which are destined at entities outside of the
   local network. By rejecting messages and removing headers, the
   proxies keep the MIOs and MFOs within the local network.
   End-to-middle and middle-to-end encryption can be used to further
   protect the MIOs and MFOs so that they can't be examined by
   unauthorized entities even if these packets accidentally leave the
   local network.


   In the separate channel model, UAs exchange MIOs and MFOs on a
   separate channel directly with the policy server. UAs can therefore
   disclose different aspects of a session description to each server.
   Each server can return policies directly to the UA. End-to-end
   encryption can be used to secure these transmissions. If UA and the
   policy server are in the same network, the MIOs and MFOs never exit
   that network.


5.2  UA Support of Policies


   In the piggyback model (alternative 1) both UAs need to support
   policies, even if they are only used in one of the domains.


   In the piggyback model (alternative 2) and the separate channel
   model, it is sufficient if one of the UAs supports policies.


5.3  Re-Use of Document Formats and Mechanisms


   The piggyback model (both alternatives) requires that proxy servers
   insert MFOs into SIP messages. The current standards require the use
   of headers for this purpose, since a proxy is not allowed to add body




Hilt & Camarillo        Expires January 8, 2005                [Page 13]
Internet-Draft          Session Policy Scenarios               July 2004



   elements to a message. As a consequence, standard document formats
   that could be used in MIME bodies can't be used for MFOs in the
   piggyback model. In addition, S/MIME encryption doesn't apply.


   In the separate channel model, MIOs and MFOs are exchanged over a
   separate channel which is potentially able to carry arbitrary
   documents. This enables the use of existing document formats for MIOs
   and MFOs and the use of encryption. In particular, the document
   formats that are defined for session-independent policies [2] can be
   re-used for session-specific policies. This greatly simplifies UAs
   which support both types of policies.


5.4  Asynchronous Policies


   Some scenarios require that a policy server can update the session
   policies at any time for ongoing sessions.


   In the piggyback model (both alternatives), the exchange of policies
   is tied to UA initiated offer/answer exchanges of session
   descriptions (i.e. INVITE, re-INVITE or UPDATE). For this reason, a
   proxy can't introduce new policies at arbitrary times during a
   session.


   In the separate channel model, the policy server can send updates for
   the current policy at any time, independent of messages exchanged
   between the UAs.


5.5  Separation of Tasks


   It is generally desirable to develop separate solutions for different
   tasks. In the piggyback model (both alternatives), the task of
   exchanging MIOs and MFOs between UA and policy server is coupled to
   the task of exchanging the offer/answer between UAC and UAS. This
   increases the complexity of call flows, in particular if the
   transmission of MIO/MFOs is spread across different SIP transactions,
   and leads lower re-usability of solutions for each task.


   The separate channel model provides a clear separation of tasks.


6  References


   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.


   [2]  Hilt, V., Camarillo, G. and J. Rosenberg, "Session-Independent
        Policies for the Session Initiation Protocol (SIP)",
        draft-hilt-sipping-session-indep-policy-01 (work in progress),
        May 2004.




Hilt & Camarillo        Expires January 8, 2005                [Page 14]
Internet-Draft          Session Policy Scenarios               July 2004



   [3]  Hilt, V. and J. Rosenberg, "A Framework for Session-Specific
        Intermediary Session Policies in SIP",
        draft-hilt-sipping-session-spec-policy-00 (work in progress),
        September 2003.


   [4]  Petrie, D., "A Framework for Session Initiation Protocol User
        Agent Profile Delivery", draft-ietf-sipping-config-framework-03
        (work in progress), May 2004.


   [5]  Rosenberg, J., "Requirements for Session Policy for the Session
        Initiation Protocol  (SIP)",
        draft-ietf-sipping-session-policy-req-01 (work in progress),
        February 2004.


   [6]  Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A.
        Rayhan, "Middlebox communication architecture and framework",
        RFC 3303, August 2002.



Authors' Addresses


   Volker Hilt
   Bell Labs/Lucent Technologies
   101 Crawfords Corner Rd
   Holmdel, NJ  07733
   USA


   EMail: volkerh@bell-labs.com



   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland


   EMail: Gonzalo.Camarillo@ericsson.com


Appendix A.  Acknowledgements


   Many thanks to Jonathan Rosenberg and Allison Mankin.











Hilt & Camarillo        Expires January 8, 2005                [Page 15]
Internet-Draft          Session Policy Scenarios               July 2004



Intellectual Property Statement


   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 IETF's procedures with respect to rights in IETF 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.



Disclaimer of Validity


   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.



Copyright Statement


   Copyright (C) The Internet Society (2004). 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.



Acknowledgment


   Funding for the RFC Editor function is currently provided by the
   Internet Society.





Hilt & Camarillo        Expires January 8, 2005                [Page 16]