SIP Working Group                                           W. Marshall 
Internet Draft                                                     AT&T 
Document: <draft-ietf-sip-call-auth-03.txt>                             
                                                        K. Ramakrishnan 
                                                     TeraOptic Networks 
                                                                        
                                                              E. Miller 
                                                                Terayon 
                                                                        
                                                             G. Russell 
                                                              CableLabs 
                                                                         
                                                                B. Beser 
                                                       Pacific Broadband 
                                                                         
                                                             M. Mannette 
                                                         K. Steinbrenner 
                                                                    3Com 
                                                                         
                                                                 D. Oran 
                                                            F. Andreasen 
                                                                     Cisco 
                                                                           
                                                                J. Pickens 
                                                                     Com21 
                                                                           
                                                               P. Lalwaney 
                                                                     Nokia 
                                                                           
                                                                J. Fellows 
                                               Copper Mountain Networks 
                                                                        
                                                               D. Evans 
                                                 D. R. Evans Consulting 
                                                                        
                                                               K. Kelly 
                                                               NetSpeak 
                                                                        
                                                         November, 2001 
    
    
                   SIP Extensions for Media Authorization  
 
 
Status of this Memo 
 
   This document is an Internet-Draft and is in full conformance with all 
   provisions of Section 10 of RFC2026 [1].  
    
   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."  
   SIP Working Group      Expiration 5/31/02                        1 

                SIP Extensions for Media Authorization   November 2001 
 
    
   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. 
    
   The distribution of this memo is unlimited.  It is filed as <draft-ietf-
   sip-call-auth-03.txt>, and expires May 31, 2002. Please send comments to 
   the authors. 
    
1. Abstract 
    
   This document describes the need for call authorization and offers a 
   mechanism for call authorization that can be used for admission control 
   and against denial of service attacks.  
    
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 
 
   The current IP Telephony systems consider a perfect world in which there 
   is unlimited amount of bandwidth and network layer QoS comes free.  The 
   reality is that bandwidth is neither unlimited nor free. Enhanced quality 
   of service, as required for high-grade voice communication, needs special 
   authorization for better than 'best-effort' service.  Without such a 
   capability, it is possible that a single berserk IP telephony device can 
   cause denial of service to a significant number of others.  
    
4. Overview 
    
   Integration of Media Authorization and Call Signaling architecture 
   consists of User Agents (UAs) which are considered untrusted, and SIP-
   Proxy which authorizes the call that is initiated by UA. 
    
   The SIP-Proxy authorizes the Media data flow to/from the UA and returns 
   to the UA a Media-Authorization-Token, which is to be used for 
   authorization when bandwidth is requested for the data-stream. 
    
   When the UA is ready to send the media data-stream to the other end-
   point, it first requests bandwidth, using the Authorization-Token it 
   received from its SIP-Proxy. 
 
5. Changes to SIP to Support Media Authorization 
    
   This document extends SIP in support of an authorization scheme. In this 
   architecture the SIP-Proxy supplies the UA an Authorization-Token which 
   is to be used for bandwidth requests. The extension defined allows 
   network resources to be authorized by the SIP-Proxy. 
    

    SIP Working Group     Expiration 5/31/02                        2 

                SIP Extensions for Media Authorization   November 2001 
 
   The following syntax specification uses the augmented Backus-Naur Form 
   (BNF) as described in RFC-2234 [3]. 
 
5.1 SIP Header Extension 
 
   The Media-Auth-Token general header conveys an identifier of the local 
   Gate to a UA.  This information is used for authorizing the Media Stream. 
    
        Media-Auth       = "Media-Authorization" ":"  
                                Media-Authorization-Token  
         
        Media-Authorization-Token       = 1*hex 
    
    
   Table 1 below is an extension of tables 4 and 5 in [4] for the new header 
   field defined here: 
  
                      where  enc.  e-e  ACK  BYE  CAN  INV  OPT  REG 
    Media-Authorization g     n     h    -    -    -    o    -    - 
    
                      Table 1: Summary of header fields. 
    
   The Media-Authorization header can be used with the INVITE method as well 
   as any response to it. 
    
5.2 SIP Procedures 
    
   This section defines a SIP [4] profile for usage in Media Authorization 
   compatible systems from the point of view of Authorizing Calls.  
    
   The initial SIP INVITE message, as well as mid-call resource change 
   messages and mid-call changes in call destination should be authorized.  
   These SIP messages are sent through the proxies to receive this 
   authorization. 
    
5.2.1. User Agent Client (UAC) 
    
   The Media-Auth-Token, contained in the Media-Authorization header, is 
   included in the first non-100 response message sent by the SIP-Proxy to 
   the UAC.  
    
   The UAC SHOULD use the Media-Authorization-Token when requesting 
   bandwidth for Media data stream during initiation and retaining of the 
   bandwidth.  The UAC converts the string of hex digits into binary, and 
   utilizes the result as a Policy-Element as defined in RFC2750[8].  This 
   Policy-Element would typically contain the authorizing entity and 
   credentials, and be used in an RSVP request for media data stream 
   resources. 
    
5.2.2. User Agent Server (UAS) 
    
   The User Agent Server receives the Media-Authorization-Token in the 
   INVITE message from SIP-Proxy. 
    

    SIP Working Group     Expiration 5/31/02                        3 

                SIP Extensions for Media Authorization   November 2001 
 
   The UAS SHOULD use the Media-Authorization-Token when requesting 
   bandwidth for media data stream during initiation and retaining of the 
   bandwidth. The UAS converts the string of hex digits into binary, and 
   utilizes the result as a Policy-Element as defined in RFC2750[8].  This 
   Policy-Element would typically contain the authorizing entity and 
   credentials, and be used in an RSVP request for media data stream 
   resources. 
    
5.2.3. Originating Proxy (OP) 
    
   The Originating Proxy (OP) authenticates the caller, and verifies the 
   caller is authorized to receive the requested level of QoS.  In 
   cooperation with originating Policy Decision Point (PDP-o), the OP 
   obtains and/or generates a Media-Authorization-Token that contains 
   sufficient information for the UAC to get the authorized bandwidth for 
   the media streams.  The Media-Authorization-Token is formatted as a 
   Policy-Element, as defined in RFC2750[8], and converted to a string of 
   hex digits. 
    
   The Originating Proxy MUST insert the Media-Authorization header in the 
   first non-100 response message that it sends to the UAC.  
    
    
5.2.4. Destination Proxy (DP) 
    
   The Destination Proxy (DP) authenticates the called party, and verifies 
   the called party is authorized to receive the requested level of QoS.  In 
   cooperation with terminating Policy Decision Point (PDP-t), the DP 
   obtains and/or generates a Media-Authorization-Token that contains 
   sufficient information for the destination server to get the authorized 
   bandwidth for the media streams.  The Media-Authorization-Token is 
   formatted as a Policy-Element, as defined in RFC2750[8], and converted to 
   a string of hex digits. 
    
   The Destination Proxy MUST insert the Media-Authorization header in the 
   INVITE message that it sends to the UAS.  
 
6. Examples 
 
6.1. Requesting Bandwidth via RSVP messaging 
    
   Resource Reservation Protocol (RSVP) is the end-to-end Layer 3 
   reservation protocol that is widely used [7]. These examples further 
   assume that resource management is integrated with SIP signaling, 
   therefore utilizing the 183 Session Progress provisional response, 
   containing an SDP description of the media flow. 
    
6.1.1. User Agent Client Side 
    
   Figure 1 presents a high-level overview of a basic call flow with Media 
   Authorization from the viewpoint of the UAC. It is assumed that the SIP-
   Proxy has a previously established authentication relationship with the 
   client.  
    

    SIP Working Group     Expiration 5/31/02                        4 

                SIP Extensions for Media Authorization   November 2001 
 
   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 Originating 
   SIP-Proxy. 
    
   The Originating SIP-Proxy (OP) authenticates UAC and forwards the 
   (2)INVITE message to the proper SIP-proxy. 
    
   Assuming that the call is not forwarded, the other end-point sends a 
   (3)183 response to the initial INVITE, proxied back to OP. Included in 
   this response is the negotiated bandwidth requirement for the connection. 
    
   When OP receives the (3)183, 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. 





































    SIP Working Group     Expiration 5/31/02                        5 

                SIP Extensions for Media Authorization   November 2001 
 
   UAC         ER-o            PDP-o           OP 
   |(1)Invite   |               |               | Client Authentication 
   |------------------------------------------->| and Call Authorization 
   |            |               |               | (2)Invite 
   |            |               |               |--------------> 
   |            |               |               | (3)180/3 
   |            |               |(4)AuthProfile |<--------------  
   |            |               |<--------------| 
   |            |               |(5)AuthToken   | 
   |            |               |-------------->| Auth. Token put into 
   |            |               |(6)180/3       | Media-Authorization header 
   |<-------------------------------------------| extension. 
   |Copies the RSVP policy object               | 
   |from the Media-Authorization                | 
   |(7)RSVP-PATHo               |               | 
   |----------->| (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-PATHo 
   |            |------------------------------------------------> 
   |            |               |               |(11)RSVP-PATHt 
   |<-------------------------------------------------------------- 
   |Copies the RSVP policy object               | 
   |from the Media-Authorization                | 
   |(12)RSVP-RESVt              |               | 
   |----------->|   (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-RESVt 
   |            |---------------------------------------------------> 
   |            |               |               |(16)RSVP-RESVo 
   |<---------------------------------------------------------------- 
   |            |               |               |(17)RSVP-RESVCONFo 
   |----------------------------------------------------------------> 
   |            |               |               |(18)RSVP-RESVCONFt 
   |<---------------------------------------------------------------- 
   |            |               |               |(19)200 OK 
   |<-------------------------------------------|<------------------ 
   |            |               |               |   MEDIA 
   |<===============================================================> 
   |            |               |               |(20)ACK  
   |----------------------------------------------------------------> 
                                       
                                  Figure 1









    SIP Working Group     Expiration 5/31/02                        6 

                SIP Extensions for Media Authorization   November 2001 
 
                                       
   The OP includes the Authorization-Token in the Media-Auth-Token header 
   extension of the (6)183 message. 
    
   Upon receipt of the (6)183 message, the UAC stores the Media-
   Authorization-Token. 
    
   Before sending the Media stream, the UAC requests bandwidth using an 
   (7)RSVP-PATH message which includes the Session info that describes the 
   Media data-stream and TSpec that describes the bandwidth requested along 
   with in the previously stored Media-Authorization-Token.  
    
   ERo, upon reception of the (7)RSVP-PATHo message checks the authorization 
   through a PDP-o COPS message exchange, (8)REQ. The PDPo checks the 
   authorization using the stored authorized Media description that was 
   linked to Authorization-Token that it returned to OP. If authorization is 
   successful PDPo returns an "install" Decision, (9)DEC.  
    
   ERo checks the admissibility for the call and if admission succeeds, it 
   forwards the (10)RSVP-PATHo message. 
    
   Once UAC receives the (11)RSVP-PATHt message it sends (12)RSVP-RESVt 
   message to reserve the bandwidth. 
    
   ERo, upon reception of the (12)RSVP-RESVt message checks the 
   authorization through a PDPo COPS message exchange, (13)REQ. The PDPo 
   checks the authorization using the stored authorized Media description 
   that was linked to Authorization-Token that it returned to OP. If 
   authorization is successful PDPo returns an "install" Decision, (14)DEC.  
    
   ERo checks the admissibility for the call and if admission succeeds, it 
   forwards the (15)RSVP-RESVt message. 
    
   Upon reception of (16)RSVP-RESVo message the UAC sends (17)RSVP-RESVCONFo 
   message to indicate that the reservation completed for one direction.  
    
   Upon reception of both (18)RSVP-RESVCONFt and (19)200OK the UAC returns 
   (20)ACK message. 
 
6.1.2. User Agent Server Side 
 
   Figure 2 presents a high-level overview of a call flow with Media 
   Authorization from the viewpoint of the UAS. It is assumed that the SIP-
   Proxy has a previously established authentication relationship with the 
   client.  
    
   Since the Destination SIP-Proxy (DP) has sufficient information regarding 
   the end-points, bandwidth and characteristics of the media exchange, it 
   initiates a Policy-Setup message to the termination Policy Decision Point 
   (PDPt) on receipt of the (1)INVITE.  
    
    
    
    
    
    SIP Working Group     Expiration 5/31/02                        7 

                SIP Extensions for Media Authorization   November 2001 
 
   UAS         ERt             PDPt           DP 
    |           |               |               | (1)Invite 
    |           |               |               |<-------------- 
    |           |               |               | Proxy Authentication 
    |           |               | (2)AuthProfile| and Call Authorization 
    |           |               |<--------------| 
    |           |               |  (3)AuthToken | 
    |           |               |-------------->| Auth. Token put into 
    |           |               |  (4)Invite    | Media-Authorization header 
    |<------------------------------------------| extension 
    |  (5)180/3 |               |               | 
    |------------------------------------------>| (6)180/3  
    |Copies the RSVP policy object              |--------------> 
    |from the Media-Authorization               | 
    |(7)RSVP-PATHt              |               | 
    |---------->| (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-PATHt 
    |           |--------------------------------------------------> 
    |           |               |               |(11)RSVP-PATHo 
    |<-------------------------------------------------------------- 
    |Copies the RSVP policy object              | 
    |from the Media-Authorization               | 
    | (12)RSVP-RESVo            |               |        
    |---------->|               |               |        
    |           | (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-RESVo 
    |           |---------------------------------------------------> 
    |           |               |               |(16)RSVP-RESVt 
    |<--------------------------------------------------------------- 
    |           |               |               |(17)RSVP-RESVCONFt 
    |---------------------------------------------------------------> 
    |           |               |               |(18)RSVP-RESVCONFo 
    |<--------------------------------------------------------------- 
    |           |               |               |(19)200 OK 
    |-----------------------------------------> |-------------------> 
    |           |               |               |(20)ACK 
    |<---------------------------------------------------------------- 
                                        Figure 2











    SIP Working Group     Expiration 5/31/02                        8 

                SIP Extensions for Media Authorization   November 2001 
 
                                 
   The 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. 
    
   Assuming that the call is not forwarded, the UAS sends a (5)183 response 
   to the initial INVITE message, which is forwarded back to UAC. At the 
   same time UAS sends (7)RSVP-PATHt message for Media data-stream that 
   includes the Session info that describes the Media data-stream and TSpec 
   that describes the bandwidth requested along with Authorization 
   information that was stored in Media-Authorization-Token.  
    
   ERt, upon reception of the (7)RSVP-PATHt message checks the authorization 
   through a PDPt COPS message exchange. The PDPt checks the authorization 
   using the stored authorized Media description that was linked to 
   Authorization-Token that it returned to DP. If authorization is 
   successful PDPt returns an "install" Decision, (9)DEC.  
    
   ERt checks the admissibility for the call and if admission succeeds, it 
   forwards the (10)RSVP-PATHt message. 
    
   Once the UAS receives the (11)RSVP-PATHo message, it sends (12)RSVP-RESVo 
   message to reserve the bandwidth. 
    
   ERt, upon reception of the (12)RSVP-RESVo message, checks the 
   authorization through a PDPt COPS message exchange. The PDPt checks the 
   authorization using the stored authorized Media description that was 
   linked to Authorization-Token that it returned to DP. If authorization is 
   successful PDPt returns an "install" Decision, (14)DEC.  
    
   ERt checks the admissibility for the call and if admission succeeds, it 
   forwards the (15)RSVP-RESVo message. 
    
   Upon reception of (16)RSVP-RESVt message the UAS sends (17)RSVP-RESVCONFt 
   message to indicate that the reservation completed for one direction.  
    
   Upon reception of the (18)RSVP-RESVCONFo, the UAS sends the (19)200OK and 
   awaits the (20)ACK response from the far end UAC. 
    
6.2. Requesting Bandwidth via DOCSIS MAC messaging 
                                        
   The DOCSIS MAC layer [5] QoS Set-Up the call flows are different in the 
   sense that the Authorization token is a simple 32bit number [6], encoded 
   as a Policy-Element. DSA-REQ, DSA-RSP, and DSA-ACK are layer 2 messages 
   that are specific to and optimized for the Cable environment which 
   simplifies/reduces delays for the embedded client implementation [6]. 
   
    
   




    SIP Working Group     Expiration 5/31/02                        9 

                SIP Extensions for Media Authorization   November 2001 
 
   UAC               ER/CMTSo                  OP 
   |  Invite            |                       | 
   |------------------------------------------->| Client Authentication 
   |                    |                       |and Call Authorization 
   |                    |                       |  
   |                    |                       | Invite 
   |                    |                       |-----------> 
   |                    |                       | 
   |                    |                       | 180/3 OK 
   |                    |                       |<------------ 
   |                    |                       | 
   |                    |  Gate-Setup           |  
   |                    |<--------------------- | 
   |                    |       Gate-Setup-Ack  | 
   |                    |---------------------> | 
   |                    |                       | GateID put into 
   |                    |                       | Media-Authorization header 
   |                    |                       | extension 
   |                    |       180/3 OK        | 
   |<-------------------------------------------| 
   |Copies the GAteID object                    | 
   |from the Media-Authorization                | 
   |                    |                       | 
   | DSA-REQ            |                       | 
   |------------------->|                       |                        
   |                    | Using the GateID and the Profile 
   |                    | communicated during Gate-Setup 
   |                    | the CMTS honors the request and creates 
   | DSA-RSP            | a scheduler with appropriate settings 
   |<-------------------|                       |                        
   |                    |                       |                        
   | DSA-ACK            |                       |                        
   |------------------->|                       |                        
   |                    |                       |                        
   
                                Figure 3 
                                        
6.2.1. User Agent Client Side 
   
   Figure 3 presents a high-level overview of a call flow with Media 
   Authorization from the viewpoint of the UAC.  It is assumed that the SIP-
   Proxy has a previously established authentication relationship with the 
   client.  
    
   When a user goes off-hook and dials a telephone number, the originating 
   SIP Client (UAC) collects the dialed digits and sends the initial INVITE 
   message to Originating SIP-Proxy. 
    
   The Originating SIP-Proxy (OP) authenticates UAC and forwards the INVITE 
   message to the proper destination SIP-proxy. 
    
   Assuming that the call is not forwarded, the other end-point sends a 183 
   response to the initial INVITE, forwarded back to OP. Included in this 
   response is the negotiated bandwidth requirement for the connection. 
    SIP Working Group     Expiration 5/31/02                       10 

                SIP Extensions for Media Authorization   November 2001 
 
    
   When OP receives the 183, it has sufficient information regarding the 
   end-points, bandwidth and characteristics of the media exchange. It sends 
   a Gate-Setup message to ER/CMTSo containing Media data-stream description 
   and bandwidth characteristics. The ER/CMTSo returns a 32 bit index value 
   that inside ER/CMTSo points to Media definition that OP send out. 
    
   UAC sends DSA-REQ message asking for bandwidth, which includes the 32 bit 
   index value.  
    
   ER/CMTSo, upon reception of the DSA-REQ message uses the index value to 
   find the authorized media description. Checks the requested media link 
   against authorized if the both authorization and admission succeeds it 
   starts a layer 2 link for Media data-stream on the Cable Access link and 
   returns DSA-RSP, which is acknowledged by UAC via DSA-ACK message. 
    
    
6.2.2. User Agent Server Side 
 
   Figure 4 presents a high-level overview of a basic call flow with Media 
   Authorization from the viewpoint of the UAS. It is assumed that the 
   Destination SIP-Proxy (DP) has a previously established authentication 
   relationship with the UAS.  
    
   When DP receives the (1)INVITE message, it has sufficient information 
   regarding the end-points, bandwidth and characteristics of the media 
   exchange. It sends a (2)Gate-Setup message to ER/CMTSt containing Media 
   data-stream description and bandwidth characteristics. The ER/CMTSt 
   returns a 32 bit index value that inside ER/CMTSt points to Media 
   definition that DP send out. 
    
   The DP includes the 32 bit index value in the Media-Auth-Token header 
   extension that it includes in the (4)INVITE message. 
    
   The UAS sends a (5)183 response to the initial INVITE, which is forwarded 
   back to UAC. At the same time UAS sends (7)DSA-REQ message asking for 
   bandwidth which includes the 32 bit index value.  
    
   ER/CMTSt, upon reception of the (7)DSA-REQ message uses the index value 
   to find the authorized media description. Checks the requested media link 
   against authorized if the both authorization and admission succeeds it 
   starts a layer 2 link for Media data-stream on the Cable Access link and 
   returns (8)DSA-RSP. Upon reception of (8)DSA-RSP the UAS returns (9)DSA-
   ACK message.  After sending the (9)DSA-ACK, the UAS sends a (10)200 OK to 
   the DP.  The (10)200 OK is acknowledged by an (12)ACK from the UAC to the 
   UAS. 
    
    
    
    
    
    
    
    
    
    SIP Working Group     Expiration 5/31/02                       11 

                SIP Extensions for Media Authorization   November 2001 
 
   UAS              ER/CMTSt                   DP 
   |                    |                       |  
   |                    |                       | (1)Invite 
   |                    |                       |<----------- 
   |                    |                       | Proxy Authentication 
   |                    |                       | and Call Authorization 
   |                    |(2)Gate-Setup          |  
   |                    |<----------------------| 
   |                    |    (3)Gate-Setup-Ack  | 
   |                    |---------------------->| 
   |                    |                       | GateID put into 
   |                    |                       | Media-Authorization header 
   |                    |                       | extension 
   |  (4)Invite         |                       |  
   |<-------------------------------------------|  
   |                    |                       | 
   |                    |   (5)180/3            | 
   |------------------------------------------->| 
   |                    |                       | (6)180/3  
   |                    |                       |------------> 
   |Copies the GateID object                    | 
   |from the Media-Authorization                | 
   |                    |                       | 
   | (7)DSA-REQ         |                        
   |------------------->|                                                
   |                    | Using the GateID and the Profile 
   |                    | communicated during Gate-Setup 
   |                    | the CMTS honors the request and creates 
   | (8)DSA-RSP         | a scheduler with appropriate settings 
   |<-------------------|                                                
   |                    |                                                
   | (9)DSA-ACK         |                       |                        
   |------------------->|                       |                        
   |                    |                       |                        
   |                    |   (10)200 OK          | 
   |------------------------------------------->| 
   |                    |                       | (11)200 OK 
   |                    |                       |------------> 
   |  (12)ACK           |                       |  
   |<--------------------------------------------------------- 
    
                                Figure 4













    SIP Working Group     Expiration 5/31/02                       12 

                SIP Extensions for Media Authorization   November 2001 
 
                         
    
7. Advantages of the Proposed Approach 
    
   The use of call authorization makes it possible to control the 
   utilization of network resources. This in turn makes IP Telephony more 
   robust against denial of service attacks and various kinds of service 
   frauds. 
    
   Using the authorization capability, the service provider can control the 
   number of flows, the amount of bandwidth, and the end-point reached 
   making the IP Telephony system dependable in the presence of scarce 
   resources. 
    
    
8. Security Considerations 
 
   Media Authorization Tokens sent from a SIP-Proxy to a UAC/UAS MUST be 
   protected from eavesdropping, through a mechanism such as IPSec. 
    
    
9. 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. 
    
10. Reference
 
   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  Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 
      Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon 
      Internet Ltd., November 1997 
      
   4  M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 
      session initiation protocol,"Request for Comments (Proposed 
      Standard) 2543, Internet Engineering Task Force, Mar. 1999. 
    
   5  CableLabs, "Data-Over-Cable Service Interface Specifications, Radio 
      Frequency Interface Specification, SP-RFIv1.1-I04-000407", April 2000. 
    
   6  PacketCable, Dynamic Quality of Service Specification, pkt-sp-dqos-
      i01-991201, December 1, 1999. 
    
   7  Wroclawski, J, RFC 2210, The Use of RSVP with IETF Integrated    
       Services, RFC2210, September 1997. 
    
   8  Herzog, S, RSVP Extensions for Policy Control, RFC2750, January 2000. 
 
11. Acknowledgments 
    SIP Working Group     Expiration 5/31/02                       13 

                SIP Extensions for Media Authorization   November 2001 
 
 
    
   The Distributed Call Signaling work in the PacketCable project is 
   the work of a large number of people, representing many different 
   companies.  The authors would like to recognize and thank the 
   following for their assistance: John Wheeler, Motorola; David 
   Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows, 
   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. 
    
13. Author's Addresses 
    
   Bill Marshall 
   AT&T 
   Florham Park, NJ  07932 
   Email: wtm@research.att.com  
    
   K. K. Ramakrishnan 
   TeraOptic Networks 
   Summit, NJ  07901 
   Email: kk@teraoptic.com  
    
   Ed Miller 
   Terayon 
   Louisville, CO  80027 
   Email: E.Miller@terayon.com  
    
   Glenn Russell 
   CableLabs 
   Louisville, CO  80027 
   Email: G.Russell@Cablelabs.com 
    
   Burcak Beser 
   Pacific Broadband Communications 
   San Jose, CA 
   Email: Burcak@pacband.com 
    
   Mike Mannette 
   3Com 
   Rolling Meadows, IL  60008 
   Email: Michael_Mannette@3com.com 
    
   Kurt Steinbrenner 
   3Com 
   Rolling Meadows, IL  60008 
   Email: Kurt_Steinbrenner@3com.com 
    
   Dave Oran 
   Cisco 
  
    SIP Working Group     Expiration 5/31/02                       14 
 

                SIP Extensions for Media Authorization   November 2001 
 
 
   Acton, MA  01720 
   Email: oran@cisco.com 
    
   Flemming Andreasen 
   Cisco 
   Edison, NJ 
   Email: fandreas@cisco.com 
    
   John Pickens 
   Com21 
   San Jose, CA 
   Email: jpickens@com21.com 
    
   Poornima Lalwaney 
   Nokia 
   San Diego, CA  92121 
   Email: poornima.lalwaney@nokia.com 
    
   Jon Fellows 
   Copper Mountain Networks 
   San Diego, CA  92121 
   Email: jfellows@coppermountain.com 
    
   Doc Evans 
   D. R. Evans Consulting 
   Boulder, CO  80303 
   Email: n7dr@arrl.net 
    
   Keith Kelly 
   NetSpeak 
   Boca Raton, FL  33587 
   Email: keith@netspeak.com 
    
    


















  
    SIP Working Group     Expiration 5/31/02                       15 
 

                SIP Extensions for Media Authorization   November 2001 
 
 
    
Full Copyright Statement 
 
   "Copyright (C) The Internet Society (date). 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 implmentation 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." 
    
   Expiration Date This memo is filed as <draft-ietf-sip-call-auth-
   03.txt>, and expires May 31, 2002. 
    
    
    
    





















  
    SIP Working Group     Expiration 5/31/02                       16