doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc3313.txt b/doc/rfc/rfc3313.txt
new file mode 100644
index 0000000..45b4a3f
--- /dev/null
+++ b/doc/rfc/rfc3313.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                   W. Marshall, Ed.
+Request for Comments: 3313                                          AT&T
+Category: Informational                                     January 2003
+
+
+          Private Session Initiation Protocol (SIP) Extensions
+                        for Media Authorization
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document describes the need for Quality of Service (QoS) and
+   media authorization and defines a Session Initiation Protocol (SIP)
+   extension that can be used to integrate QoS admission control with
+   call signaling and help guard against denial of service attacks.  The
+   use of this extension is only applicable in administrative domains,
+   or among federations of administrative domains with previously
+   agreed-upon policies, where both the SIP proxy authorizing the QoS,
+   and the policy control of the underlying network providing the QoS,
+   belong to that administrative domain or federation of domains.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Marshall, Ed.                Informational                      [Page 1]
+
+RFC 3313         SIP Extensions for Media Authorization     January 2003
+
+
+Table of Contents
+
+   1. Scope of Applicability.........................................  2
+   2. Conventions Used in this Document..............................  3
+   3. Background and Motivation......................................  3
+   4. Overview.......................................................  4
+   5. Changes to SIP to Support Media Authorization..................  4
+      5.1 SIP Header Extension.......................................  5
+      5.2 SIP Procedures.............................................  5
+        5.2.1 User Agent Client (UAC)................................  6
+        5.2.2 User Agent Server (UAS)................................  6
+        5.2.3 Originating Proxy (OP).................................  7
+        5.2.4 Destination Proxy (DP).................................  7
+   6. Examples.......................................................  8
+      6.1 Requesting Bandwidth via RSVP Messaging....................  8
+        6.1.1 User Agent Client Side.................................  8
+        6.1.2 User Agent Server Side................................. 10
+   7. Advantages of the Proposed Approach............................ 12
+   8. Security Considerations........................................ 13
+   9. IANA Considerations............................................ 13
+   10. Notice Regarding Intellectual Property Rights................. 13
+   11. Normative References.......................................... 14
+   12. Informative References........................................ 14
+   13. Contributors.................................................. 15
+   14. Acknowledgments............................................... 15
+   15. Editor's Address.............................................. 15
+   16. Full Copyright Statement...................................... 16
+
+1. Scope of Applicability
+
+   This document defines a SIP extension that can be used to integrate
+   QoS admission control with call signaling and help guard against
+   denial of service attacks.  The use of this extension is only
+   applicable in administrative domains, or among federations of
+   administrative domains with previously agreed-upon policies, where
+   both the SIP proxy authorizing the QoS, and the policy control of the
+   underlying network providing the QoS, belong to that administrative
+   domain or federation of domains.  Furthermore, the mechanism is
+   generally incompatible with end-to-end encryption of message bodies
+   that describe media sessions.
+
+   This is in contrast with general Internet principles, which separate
+   data transport from applications.  Thus, the solution described in
+   this document is not applicable to the Internet at large.  Despite
+   these limitations, there are sufficiently useful specialized
+   deployments that meet the assumptions described above, and can accept
+   the limitations that result, to warrant informational publication of
+   this mechanism.  An example deployment would be a closed network,
+
+
+
+Marshall, Ed.                Informational                      [Page 2]
+
+RFC 3313         SIP Extensions for Media Authorization     January 2003
+
+
+   which emulates a traditional circuit switched telephone network.
+   This document specifies a private header, facilitating use in these
+   specialized configurations.
+
+2. Conventions Used in this Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [2].
+
+3. Background and Motivation
+
+   Current IP telephony systems assume a perfect world in which there is
+   either an unlimited amount of bandwidth, or network layer Quality of
+   Service (QoS) is provided without any kind of policy control.
+   However, the reality is that end-to-end bandwidth is not unlimited
+   and uncontrolled access to QoS, in general, is unlikely.  The primary
+   reason for this is that QoS provides preferential treatment of one
+   flow, at the expense of another.  Consequently, it is important to
+   have policy control over whether a given flow should have access to
+   QoS.  This will not only enable fairness in general, but can also
+   prevent denial of service attacks.
+
+   In this document, we are concerned with providing QoS for media
+   streams established via the Session Initiation Protocol (SIP) [3].
+   We assume an architecture that integrates call signaling with media
+   authorization, as illustrated in the Figure below.  The solid lines
+   (A and B) show interfaces, whereas the dotted line (C) illustrates
+   the QoS enabled media flow:
+
+                               +---------+
+                               |  Proxy  |
+                    +--------->|         |
+                    |          +---------+
+                    |               ^
+                  A)|            B) |
+                    |              { }
+                    |               |
+                    |               v
+                    v           +------+
+                +------+   C)   | Edge |
+                |  UA  |........|router|......
+                +------+        +------+
+
+
+                       Figure 1 - Basic Architecture
+
+
+
+
+
+Marshall, Ed.                Informational                      [Page 3]
+
+RFC 3313         SIP Extensions for Media Authorization     January 2003
+
+
+   In this architecture, we assume a SIP UA connected to a QoS enabled
+   network with an edge router acting as a Policy Enforcement Point
+   (PEP) [6].  We further assume that a SIP UA that wishes to obtain QoS
+   initiates sessions through a proxy which can interface with the QoS
+   policy control for the data network being used.  We will refer to
+   such a proxy as a QoS enabled proxy.  We assume that the SIP UA needs
+   to present an authorization token to the network in order to obtain
+   Quality of Service (C).  The SIP UA obtains this authorization token
+   via SIP (A) from the QoS enabled proxy by means of an extension SIP
+   header, defined in this document.  The proxy, in turn, communicates
+   either directly with the edge router or with a Policy Decision Point
+   (PDP - not shown) [6] in order to obtain a suitable authorization
+   token for the UA.
+
+   Examples of access data networks, where such a QoS enabled proxy
+   could be used, include DOCSIS based cable networks and 3rd generation
+   (3G) wireless networks.
+
+4. Overview
+
+   A session that needs to obtain QoS for the media streams in
+   accordance with our basic architecture described above goes through
+   the following steps.
+
+   The SIP UA sends an INVITE to the QoS enabled proxy, which for each
+   resulting dialog includes one or more media authorization tokens in
+   all unreliable provisional responses (except 100), the first reliable
+   1xx or 2xx response, and all retransmissions of that reliable
+   response for the dialog.  When the UA requests QoS, it includes the
+   media authorization tokens with the resource reservation.
+
+   A SIP UA may also receive an INVITE from its QoS enabled proxy which
+   includes one or more media authorization tokens.  In that case, when
+   the UA requests QoS, it includes the media authorization tokens with
+   the resource reservation.  The resource reservation mechanism is not
+   part of SIP and is not described within the scope of this document.
+
+5. Changes to SIP to Support Media Authorization
+
+   This document defines a private SIP header extension to support a
+   media authorization scheme.  In this architecture, a QoS enabled SIP
+   proxy supplies the UA with one or more authorization tokens which are
+   to be used in QoS requests.  The extension defined allows network QoS
+   resources to be authorized by the QoS enabled SIP proxy.
+
+
+
+
+
+
+
+Marshall, Ed.                Informational                      [Page 4]
+
+RFC 3313         SIP Extensions for Media Authorization     January 2003
+
+
+5.1 SIP Header Extension
+
+   A new P-Media-Authorization general header field is defined.  The P-
+   Media-Authorization header field contains one or more media
+   authorization tokens which are to be included in subsequent resource
+   reservations for the media flows associated with the session, that
+   is, passed to an independent resource reservation mechanism, which is
+   not specified here.  The media authorization tokens are used for
+   authorizing QoS for the media stream(s).  The P-Media-Authorization
+   header field is described by the following ABNF [4]:
+
+      P-Media-Authorization   = "P-Media-Authorization" HCOLON
+                                  P-Media-Authorization-Token
+                                  *(COMMA P-Media-Authorization-Token)
+
+      P-Media-Authorization-Token = 1*HEXDIG
+
+   Table 1 below is an extension of tables 2 and 3 in [3] for the new
+   header field defined here.  For informational purposes, this table
+   also includes relevant entries for standards track extension methods
+   published at the time this document was published.  The INFO, PRACK,
+   UPDATE, and SUBSCRIBE and NOTIFY methods are defined respectively in
+   [11], [9], [12], and [10].
+
+                              Where  proxy  ACK  BYE  CAN  INV  OPT  REG
+      P-Media-Authorization     R      ad    o    -    -    o    -    -
+      P-Media-Authorization    2xx     ad    -    -    -    o    -    -
+      P-Media-Authorization  101-199   ad    -    -    -    o    -    -
+
+                              Where  proxy  INF  PRA  UPD  SUB  NOT
+      P-Media-Authorization     R      ad    -    o    o    -    -
+      P-Media-Authorization    2xx     ad    -    o    o    -    -
+
+                      Table 1: Summary of header fields.
+
+   The P-Media-Authorization header field can be used only in SIP
+   requests or responses that can carry a SIP offer or answer.  This
+   naturally keeps the scope of this header field narrow.
+
+5.2 SIP Procedures
+
+   This section defines SIP [3] procedures for usage in media
+   authorization compatible systems, from the point of view of the
+   authorizing QoS.
+
+
+
+
+
+
+
+Marshall, Ed.                Informational                      [Page 5]
+
+RFC 3313         SIP Extensions for Media Authorization     January 2003
+
+
+5.2.1 User Agent Client (UAC)
+
+   The initial SIP INVITE message, mid-call messages that result in
+   network QoS resource changes, and mid-call changes in call
+   destination should be authorized.  These SIP messages are sent
+   through the QoS enabled proxies to receive this authorization.  In
+   order to authorize QoS, the QoS enabled SIP proxy MAY need to inspect
+   message bodies that describe the media streams (e.g., SDP).  Hence,
+   it is recommended (as may be appropriate within the applicability
+   scope in Section 1 of this document) that such message bodies not be
+   encrypted end-to-end.
+
+   The P-Media-Authorization-Token, which is contained in the P-Media-
+   Authorization header, is included for each dialog in all unreliable
+   provisional responses (except 100), the first reliable 1xx or 2xx
+   response, and all retransmissions of that reliable response for the
+   dialog sent by the QoS enabled SIP proxy to the UAC.
+
+   The UAC should use all the P-Media-Authorization-Tokens from the most
+   recent request/response that contained the P-Media-Authorization
+   header when requesting QoS for the associated media stream(s).  This
+   applies to both initial and subsequent refresh reservation messages
+   (for example, in an RSVP-based reservation system).  A reservation
+   function within the UAC should convert each string of hex digits into
+   binary, and utilize each result as a Policy-Element, as defined in
+   RFC 2750 [5] (excluding Length, but including P-Type which is
+   included in each token).  These Policy-Elements would typically
+   contain the authorizing entity and credentials, and be used in an
+   RSVP request for media data stream QoS resources.
+
+5.2.2 User Agent Server (UAS)
+
+   The User Agent Server receives the P-Media-Authorization-Token in an
+   INVITE (or other) message from the QoS enabled SIP proxy.  If the
+   response contains a message body that describes media streams for
+   which the UA desires QoS, it is recommended (as may be appropriate
+   within the applicability scope in Section 1 of this document) that
+   this message body not be encrypted end-to-end.
+
+   The UAS should use all the P-Media-Authorization-Tokens from the most
+   recent request/response that contained the P-Media-Authorization
+   header when requesting QoS for the associated media stream(s).  This
+   applies both to initial and subsequent refresh reservation messages
+   (for example, in an RSVP-based reservation system).  A reservation
+   function within the UAS should convert each string of hex digits into
+   binary, and utilize each result as a Policy-Element, as defined in
+   RFC 2750 [5] (excluding Length, but including P-Type which is
+   included in each token).  These Policy-Elements would typically
+
+
+
+Marshall, Ed.                Informational                      [Page 6]
+
+RFC 3313         SIP Extensions for Media Authorization     January 2003
+
+
+   contain the authorizing entity and credentials, and be used in an
+   RSVP request for media data stream QoS resources.
+
+5.2.3 Originating Proxy (OP)
+
+   When the originating QoS enabled proxy (OP) receives an INVITE (or
+   other) message from the UAC, the proxy authenticates the caller, and
+   verifies that the caller is authorized to receive QoS.
+
+   In cooperation with an originating Policy Decision Point (PDP-o), the
+   OP obtains and/or generates one or more media authorization tokens.
+   These contain sufficient information for the UAC to get the
+   authorized QoS for the media streams.  Each media authorization token
+   is formatted as a Policy-Element, as defined in RFC 2750 [5]
+   (excluding Length, but including P-Type which is included in each
+   token), and then converted to a string of hex digits to form a P-
+   Media-Authorization-Token.  The proxy's resource management function
+   may inspect message bodies that describe the media streams (e.g.,
+   SDP), in both requests and responses in order to decide what QoS to
+   authorize.
+
+   For each dialog that results from the INVITE (or other) message
+   received from the UAC, the originating proxy must add a P-Media-
+   Authorization header with the P-Media-Authorization-Token in all
+   unreliable provisional responses (except 100), the first reliable 1xx
+   or 2xx response, and all retransmissions of that reliable response
+   the proxy sends to the UAC, if that response may result in network
+   QoS changes.  A response with an SDP may result in such changes.
+
+5.2.4 Destination Proxy (DP)
+
+   The Destination QoS Enabled Proxy (DP) verifies that the called party
+   is authorized to receive QoS.
+
+   In cooperation with a terminating Policy Decision Point (PDP-t), the
+   DP obtains and/or generates a media authorization token that contains
+   sufficient information for the UAS to get the authorized QoS for the
+   media streams.  The media authorization token is formatted as a
+   Policy-Element, as defined in RFC 2750 [5] (excluding Length, but
+   including P-Type which is included in each token), and then converted
+   to a string of hex digits to form a P-Media-Authorization-Token.  The
+   proxy's resource management function may inspect message bodies that
+   describe the media streams (e.g., SDP), in both requests and
+   responses in order to decide what QoS to authorize.
+
+
+
+
+
+
+
+Marshall, Ed.                Informational                      [Page 7]
+
+RFC 3313         SIP Extensions for Media Authorization     January 2003
+
+
+   The Destination Proxy must add the P-Media-Authorization header with
+   the P-Media-Authorization-Token in the INVITE (or other) request that
+   it sends to the UAS if that message may result in network QoS
+   changes.  A message with an SDP body may result in such changes.
+
+6. Examples
+
+6.1 Requesting Bandwidth via RSVP Messaging
+
+   Below we provide an example of how the P-Media-Authorization header
+   field can be used in conjunction with the Resource Reservation
+   Protocol (RSVP) [7].  The example assumes that an offer arrives in
+   the initial INVITE and an answer arrives in a reliable provisional
+   response [9], which contains an SDP description of the media flow.
+
+6.1.1 User Agent Client Side
+
+   Figure 2 presents a high-level overview of a basic call flow with
+   media authorization from the viewpoint of the UAC.  Some policy
+   interactions have been omitted for brevity.
+
+   When a user goes off-hook and dials a telephone number, the UAC
+   collects the dialed digits and sends the initial (1)INVITE message to
+   the originating SIP proxy.
+
+   The originating SIP proxy (OP) authenticates the user/UAC and
+   forwards the (2)INVITE message to the proper SIP proxy.
+
+   Assuming the call is not forwarded, the terminating end-point sends a
+   (3)18x response to the initial INVITE via OP.  Included in this
+   response is an indication of the negotiated bandwidth requirement for
+   the connection (in the form of an SDP description [8]).
+
+   When OP receives the (3)18x, it has sufficient information regarding
+   the end-points, bandwidth and characteristics of the media exchange.
+   It initiates a Policy-Setup message to PDP-o, (4)AuthProfile.
+
+   The PDP-o stores the authorized media description in its local store,
+   generates an authorization token that points to this description, and
+   returns the authorization token to the OP, (5)AuthToken.
+
+
+
+
+
+
+
+
+
+
+
+Marshall, Ed.                Informational                      [Page 8]
+
+RFC 3313         SIP Extensions for Media Authorization     January 2003
+
+
+   UAC         ER-o            PDP-o           OP
+   |(1)INVITE   |               |               | Client Authentication
+   |------------------------------------------->| and Call Authoriz.
+   |            |               |               | (2)INVITE
+   |            |               |               |-------------->
+   |            |               |               | (3)18x
+   |            |               |(4)AuthProfile |<--------------
+   |            |               |<--------------|
+   |            |               |(5)AuthToken   |
+   |            |               |-------------->| Auth. Token put into
+   |            |               |        (6)18x | P-Media-Authorization
+   |<-------------------------------------------| header extension.
+   |---(7)PRACK-------------------------------->|
+   |                                            |--(8)PRACK---->
+   |                                            |<-(9)200 (PRACK)
+   |<--(10)200 (PRACK)--------------------------|
+   |            |               |               |
+   |Copies the RSVP policy object               |
+   |from the P-Media-Authorization              |
+   |(11)RSVP-PATH               |               |
+   |----------->| (12)REQ       |               |
+   |            |-------------->| Using the Auth-Token and Authorized
+   |            |       (13)DEC | Profile that is set by the SIP Proxy
+   |            |<--------------| the PDP makes the decision
+   |            |               |               |(14)RSVP-PATH
+   |            |------------------------------------------------>
+   |            |               |               |(15)RSVP-PATH
+   |<--------------------------------------------------------------
+   |Copies the RSVP policy object               |
+   |from the P-Media-Authorization              |
+   |(16)RSVP-RESV               |               |
+   |----------->|   (17)REQ     |               |
+   |            |-------------->| Using the Auth-Token and Authorized
+   |            |   (18)DEC     | Profile that is set by the SIP Proxy
+   |            |<--------------| the PDP makes the decision
+   |            |               |               |(19)RSVP-RESV
+   |            |--------------------------------------------------->
+   |            |               |               |(20)RSVP-RESV
+   |<----------------------------------------------------------------
+   |            |               |               |
+
+             Figure 2 - Media Authorization with RSVP (UAC)
+
+   The OP includes the authorization token in the P-Media-Authorization
+   header extension of the (6)18x message.
+
+
+
+
+
+
+Marshall, Ed.                Informational                      [Page 9]
+
+RFC 3313         SIP Extensions for Media Authorization     January 2003
+
+
+   Upon receipt of the (6)18x message, the UAC stores the media
+   authorization token from the P-Media-Authorization header.  Also, the
+   UAC acknowledges the 18x message by sending a (7)PRACK message, which
+   is responded to with (10) 200.
+
+   Before sending any media, the UAC requests QoS by sending an
+   (11)RSVP-PATH message, which includes the previously stored P-Media-
+   Authorization-Token as a Policy-Element.
+
+   ER-o, upon receipt of the (11)RSVP-PATH message, checks the
+   authorization through a PDP-o COPS message exchange, (12)REQ.  PDP-o
+   checks the authorization using the stored authorized media
+   description that was linked to the authorization token it returned to
+   OP.  If authorization is successful, PDP-o returns an "install"
+   Decision, (13)DEC.
+
+   ER-o checks the admissibility for the request, and if admission
+   succeeds, it forwards the (14)RSVP-PATH message.
+
+   Once UAC receives the (15)RSVP-PATH message from UAS, it sends the
+   (16)RSVP-RESV message to reserve the network resources.
+
+   ER-o, upon receiving the (16)RSVP-RESV message checks the
+   authorization through a PDP-o COPS message exchange, (17)REQ.  PDP-o
+   checks the authorization using the stored authorized media
+   description that was linked to the authorization token it returned to
+   OP.  If authorization is successful, PDP-o returns an "install"
+   Decision, (18)DEC.
+
+   ER-o checks the admissibility for the request, and if admission
+   succeeds, it forwards the (19)RSVP-RESV message.
+
+   Upon receiving the (20)RSVP-RESV message, network resources have been
+   reserved in both directions.
+
+6.1.2 User Agent Server Side
+
+   Figure 3 presents a high-level overview of a call flow with media
+   authorization from the viewpoint of the UAS.  Some policy
+   interactions have been omitted for brevity.
+
+   Since the destination SIP proxy (DP) has sufficient information
+   regarding the endpoints, bandwidth, and characteristics of the media
+   exchange, it initiates a Policy-Setup message to the terminating
+   Policy Decision Point (PDP-t) on receipt of the (1)INVITE.
+
+
+
+
+
+
+Marshall, Ed.                Informational                     [Page 10]
+
+RFC 3313         SIP Extensions for Media Authorization     January 2003
+
+
+   UAS         ER-t           PDP-t            DP
+    |           |               |               | (1)INVITE
+    |           |               |               |<--------------
+    |           |               |               | Proxy Authentication
+    |           |               | (2)AuthProfile| and Call Authoriz.
+    |           |               |<--------------|
+    |           |               | (3)AuthToken  |
+    |           |               |-------------->| Auth. Token put into
+    |           |               |     (4)INVITE | P-Media-Authorization
+    |<------------------------------------------| header extension
+    |  (5)18x   |               |               |
+    |------------------------------------------>| (6)18x
+    |Copies the RSVP policy object              |-------------->
+    |from the P-Media-Authorization             |
+    |(7)RSVP-PATH               |               |
+    |---------->| (8)REQ        |               |
+    |           |-------------->| Using the Auth-Token and Authorized
+    |           |       (9)DEC  | Profile that is set by the SIP Proxy
+    |           |<--------------| the PDP makes the decision
+    |           |               |               |(10)RSVP-PATH
+    |           |-------------------------------------------------->
+    |           |               |               |(11)RSVP-PATH
+    |<--------------------------------------------------------------
+    |Copies the RSVP policy object              |
+    |from the P-Media-Authorization             |
+    | (12)RSVP-RESV             |               |
+    |---------->|               |               |
+    |           | (13)REQ       |               |
+    |           |-------------->| Using the Auth-Token and Authorized
+    |           |       (14)DEC | Profile that is set by the SIP Proxy
+    |           |<--------------| the PDP makes the decision
+    |           |               |               |(15)RSVP-RESV
+    |           |--------------------------------------------------->
+    |           |               |               |(16)RSVP-RESV
+    |<---------------------------------------------------------------
+    |           |               |               |<-(17)PRACK---------
+    |<--(18)PRACK ------------------------------|
+    |---(19)200 (PRACK) ----------------------->|
+    |           |               |               |--(20)200 (PRACK)-->
+    |           |               |               |
+
+              Figure 3 - Media Authorization with RSVP (UAS)
+
+   PDP-t stores the authorized media description in its local store,
+   generates an authorization token that points to this description, and
+   returns the authorization token to DP.  The token is placed in the
+   (4)INVITE message and forwarded to the UAS.
+
+
+
+
+Marshall, Ed.                Informational                     [Page 11]
+
+RFC 3313         SIP Extensions for Media Authorization     January 2003
+
+
+   Assuming that the call is not forwarded, the UAS sends a (5)18x
+   response to the initial INVITE message, which is forwarded back to
+   UAC.  At the same time, the UAS sends a (7)RSVP-PATH message which
+   includes the previously stored P-Media-Authorization-Token as a
+   Policy-Element.
+
+   ER-t, upon receiving the (7)RSVP-PATH message checks the
+   authorization through a PDP-t COPS message exchange.  PDP-t checks
+   the authorization using the stored authorized media description that
+   was linked to the authorization token it returned to DP.  If
+   authorization is successful, PDP-t returns an "install" Decision,
+   (9)DEC.
+
+   ER-t checks the admissibility for the request, and if admission
+   succeeds, it forwards the (10)RSVP-PATH message.
+
+   Once the UAS receives the (11)RSVP-PATH message, it sends the
+   (12)RSVP-RESV message to reserve the network resources.
+
+   ER-t, upon reception of the (12)RSVP-RESV message, checks the
+   authorization through a PDP-t COPS message exchange.  PDP-t checks
+   the authorization using the stored authorized media description that
+   was linked to the authorization token that it returned to DP.  If
+   authorization is successful, PDP-t returns an "install" Decision,
+   (14)DEC.
+
+   ER-t checks the admissibility for the request and if admission
+   succeeds, it forwards the (15)RSVP-RESV message.
+
+   Upon receiving the (16)RSVP-RESV message, network resources have been
+   reserved in both directions.
+
+   For completeness, we show the (17)PRACK message for the (5) 18x
+   response and the resulting (19) 200 response acknowledging the PRACK.
+
+7. Advantages of the Proposed Approach
+
+   The use of media authorization makes it possible to control the usage
+   of network resources.  In turn, this makes IP Telephony more robust
+   against denial of service attacks and various kinds of service
+   frauds.  By using the authorization capability, the number of flows,
+   and the amount of network resources reserved can be controlled,
+   thereby making the IP Telephony system dependable in the presence of
+   scarce resources.
+
+
+
+
+
+
+
+Marshall, Ed.                Informational                     [Page 12]
+
+RFC 3313         SIP Extensions for Media Authorization     January 2003
+
+
+8. Security Considerations
+
+   In order to control access to QoS, a QoS enabled proxy should
+   authenticate the UA before providing it with a media authorization
+   token.  Both the method and policy associated with such
+   authentication are outside the scope of this document, however it
+   could, for example, be done by using standard SIP authentication
+   mechanisms, as described in [3].
+
+   Media authorization tokens sent in the P-Media-Authorization header
+   from a QoS enabled proxy to a UA MUST be protected from eavesdropping
+   and tampering.  This can, for example, be done through a mechanism
+   such as IPSec or TLS.  However, this will only provide hop-by-hop
+   security.  If there is one or more intermediaries (e.g., proxies),
+   between the UA and the QoS enabled proxy, these intermediaries will
+   have access to the P-Media-Authorization header field value, thereby
+   compromising confidentiality and integrity.  This will enable both
+   theft-of-service and denial-of-service attacks against the UA.
+   Consequently, the P-Media-Authorization header field MUST NOT be
+   available to any untrusted intermediary in the clear or without
+   integrity protection.  There is currently no mechanism defined in SIP
+   that would satisfy these requirements.  Until such a mechanism
+   exists, proxies MUST NOT send P-Media-Authorization headers through
+   untrusted intermediaries, which might reveal or modify the contents
+   of this header.  (Note that S/MIME-based encryption in SIP is not
+   available to proxy servers, as proxies are not allowed to add message
+   bodies.)
+
+   QoS enabled proxies may need to inspect message bodies describing
+   media streams (e.g., SDP).  Consequently, such message bodies should
+   not be encrypted.  In turn, this will prevent end-to-end
+   confidentiality of the said message bodies, which lowers the overall
+   security possible.
+
+9. IANA Considerations
+
+   This document defines a new private SIP header for media
+   authorization, "P-Media-Authorization".  This header has been
+   registered by the IANA in the SIP header registry, using the RFC
+   number of this document as its reference.
+
+10. Notice Regarding Intellectual Property Rights
+
+   The IETF has been notified of intellectual property rights claimed in
+   regard to some or all of the specification contained in this
+   document.  For more information consult the online list of claimed
+   rights.
+
+
+
+
+Marshall, Ed.                Informational                     [Page 13]
+
+RFC 3313         SIP Extensions for Media Authorization     January 2003
+
+
+11. Normative References
+
+   [1]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+        9, RFC 2026, October 1996.
+
+   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [3]  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.
+
+   [4]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+        Specifications: ABNF", RFC 2234, November 1997.
+
+   [5]  Herzog, S., "RSVP Extensions for Policy Control", RFC 2750,
+        January 2000.
+
+12. Informative References
+
+   [6]  Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for
+        Policy-based Admission Control", RFC 2753, January 2000.
+
+   [7]  Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
+        "Resource Reservation Protocol (RSVP) -- Version 1 Functional
+        Specification", RFC 2205, September 1997.
+
+   [8]  Handley, M. and V. Jacobson, "SDP: Session Description
+        Protocol", RFC 2327, April 1998.
+
+   [9]  Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
+        Responses in Session Initiation Protocol (SIP)", RFC 3262, June
+        2002.
+
+   [10] Roach, A. B., "Session Initiation Protocol (SIP)-Specific Event
+        Notification", RFC 3265, June 2002.
+
+   [11] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
+
+   [12] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
+        Method", RFC 3311, September 2002.
+
+
+
+
+
+
+
+
+
+
+Marshall, Ed.                Informational                     [Page 14]
+
+RFC 3313         SIP Extensions for Media Authorization     January 2003
+
+
+13. Contributors
+
+   The following people contributed significantly and were co-authors on
+   earlier versions of this document:
+
+      Bill Marshall (AT&T), K. K. Ramakrishnan (AT&T), Ed Miller
+      (Terayon), Glenn Russell (CableLabs), Burcak Beser (Juniper
+      Networks), Mike Mannette (3Com), Kurt Steinbrenner (3Com), Dave
+      Oran (Cisco), Flemming Andreasen (Cisco), John Pickens (Com21),
+      Poornima Lalwaney (Nokia), Jon Fellows (Copper Mountain Networks),
+      Doc Evans (Arris), and Keith Kelly (NetSpeak).
+
+14. Acknowledgments
+
+   The Distributed Call Signaling work in the PacketCable project is the
+   work of a large number of people, representing many different
+   companies.  The contributors would like to recognize and thank the
+   following for their assistance: John Wheeler, Motorola; David
+   Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jay Strater,
+   Jeff Ollis, Clive Holborow, Motorola; Doug Newlin, Guido Schuster,
+   Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; Farzi Khazai,
+   Nortel; John Chapman, Bill Guckel, Michael Ramalho, Cisco; Chuck
+   Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung-Hai Hsiao,
+   Partho Mishra, AT&T; Telcordia Technologies; and Lucent Cable
+   Communications.  Dean Willis and Rohan Mahy provided valuable
+   feedback as well.
+
+15. Editor's Address
+
+   Bill Marshall
+   AT&T
+   Florham Park, NJ  07932
+
+   EMail: wtm@research.att.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Marshall, Ed.                Informational                     [Page 15]
+
+RFC 3313         SIP Extensions for Media Authorization     January 2003
+
+
+16. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Marshall, Ed.                Informational                     [Page 16]
+