Internet Draft


SIP Working Group                                           W. Marshall
Internet Draft                                          K. Ramakrishnan
Document: <draft-dcsgroup-sip-call-auth-00.txt>                    AT&T
Category: Informational
                                                              E. Miller
                                                             G. Russell
                                                              CableLabs

                                                               B. Beser
                                                            M. Mannette
                                                        K. Steinbrenner
                                                                   3Com

                                                                D. Oran
                                                                  Cisco

                                                             J. Pickens
                                                                  Com21

                                                            P. Lalwaney
                                                             J. Fellows
                                                     General Instrument

                                                               D. Evans
                                                           Lucent Cable

                                                               K. Kelly
                                                               NetSpeak

                                                           F. Andreasen
                                                              Telcordia

                                                          October, 1999


  Integration of Call Authorization and Call Signaling for IP Telephony


Status of this Memo

   This document is an Internet-Draft and is NOT offered in accordance
   with Section 10 of RFC2026[1], and the author does not provide the
   IETF with any rights other than to publish as an Internet-Draft.

   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."



DCS Group    Category Informational - Expiration 4/30/00            1

           Integration of Call Authorization and SignalingOctober 1999


   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 , and expires April 30, 2000. 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.
   As a consequence, it is possible that a single berserk IP telephony
   device can cause denial of service to a significant number of
   others.

   In some networks, charges for Quality of Service (QoS) might be paid
   by one end only, instead of sharing the connection costs. In such
   cases it is important to synchronize allocation and release of
   network resources to prevent fraud.


4. Overview

   Call authorization functionality is achieved through utilization of
   two network elements discussed in the Distributed Call Signalling
   Architecture submission [3]: An Edge Router implementing a Gate, and
   a DCS-Proxy implementing a Gate Controller.

   A Gate is located in an edge device (ER) that controls the packets
   coming from the Client. The Gate might be in a router or any other
   network element that can control the IP flows selectively and can be
   considered to be an IP level classifier and filter. The unauthorized
   flows may either be dropped or sent to it's the destination using

DCS Group    Category Informational - Expiration 4/30/00            2

           Integration of Call Authorization and SignalingOctober 1999


   best effort service. The authorized flows go through the Gate, which
   is actually an IP level classifier.  It is expected that the
   handling of unauthorized flows would depend on policies of the
   service provider.

   Control of the Gate is done by a DCS-Proxy (DP) that performs the
   call authorization function. During call signaling, DP authorizes
   the call and then sends a Gate-Setup message to ER, and receives a
   token (Gate-ID) in the response from the ER. The DCS-Proxy uses this
   Gate-ID in the call signaling messages.

   The Gate-Setup message includes the bandwidth and QoS
   characteristics for which the Client is authorized, along with other
   end-point information.

   When the Client is ready to send the media stream to the other end-
   point, it first sends a Commit message, which includes the Gate-ID
   it received from its DCS-Proxy.

   When the ER receives the Commit, it retrieves the Gate-Setup that
   was previously received for the call, and checks the authorization.
   If successful, then it opens the Gate for the IP flow, which is
   defined by the end-point information and QoS characteristics, and
   returns a Success message. From that moment on, the Client owns the
   resources until it releases them.  Upon opening the Gate, the media
   flow can reach its destination with the requested QoS.

   If both Edge Routers support call authorization, then Gate-
   Coordination enables synchronization of Commit and Release
   operations using Commit-sync and Release-sync messages,
   respectively. The synchronization is very useful when only one side
   is paying for the call. It makes sure that the Commit operation does
   not succeed until the other end Commits, and a Release ensures that
   the other end also Releases the Gate.

   Throughout this document the term Multimedia Terminal Adapter (MTA)
   will be used interchangeably with Client to represent the end-points
   of the communication.


5. Basic Call Flow

   Figure 1 presents a high-level overview of a basic MTA-to-MTA call
   flow with Call Authorization. Although it is possible to have
   partial call authorization control, it is assumed that both
   endpoints need to be authorized.

   It is assumed that the DCS-Proxy has a previously established
   authentication relationship with the MTA.

   When a user goes off-hook and dials a telephone number, the
   originating Client (MTA-o) collects the dialed digits and sends the
   initial INVITE message to its DP.

DCS Group    Category Informational - Expiration 4/30/00            3

           Integration of Call Authorization and SignalingOctober 1999


   MTA-o            DP-o                DP-d                MTA-d
   |                 |                    |                     |
   |                 | INVITE             |                     |
   |      INVITE     | (DCS-Remote-Gate)  |                     |
   |---------------->|------------------->| INVITE              |
   |                 |                    | (DCS-Local-Gate)    |
   |                 |                    |-------------------->|
   |    ER-o         |                    |                     |
   |    |            |                    |             ER-t    |
   |    |            |                    | Gate-Setup  |       |
   |    |            |                    |------------>|       |
   |    |            | 200 OK             |             |       |
   |    |            | (DCS-Remote-Gate)  |     200 OK  |       |
   |    | Gate-Setup |<-------------------|<--------------------|
   |    |<-----------|                    |             |       |
   |    |            |                                  |       |
   | 200 OK          |                                  /       |
   | (DCS-Local-Gate)|                                 /        |
   |<----------------|                                /         |
   |    |                       ACK                  /          |
   |----------------------------------------------------------->|
   |    |                                          /            |
   |     \                                        /             |
   |       \                                   ER-t             |
   |         \                                  |               |
   |           ER-o                             | Commit        |
   |            |                               |<--------------|
   | Commit     |                               |               |
   |----------->|                      Admission|               |
   |            |Admission                 Check|               |
   |            |Check                          |               |
   |            |                               |               |
   |            |   Commit-Sync                 |               |
   |            |------------------------------>| Success       |
   |            |                               |-------------->|
   |            |                            {Gate}             |
   |            |   Commit-Sync              {Gate}             |
   | Success    |<---------------------------{Gate}             |
   |<-----------|                            {Gate}             |
   |         {Gate}                          {Gate}             |
   |         {Gate}     Media Stream         {Gate}             |
   |<========{Gate}=========================={Gate}============>|
   |         {Gate}                          {Gate}             |
   | Release {Gate}                          {Gate}             |
   |----------->|   Release-Sync             {Gate}             |
   |            |------------------------------>|               |
   |            |               BYE             |               |
   |----------------------------------------------------------->|
   |            |                               | Release       |
   |            |                               |<--------------|
   |            |   Release-Sync                |               |
   |            |<------------------------------|               |
                                 Figure 1

DCS Group    Category Informational - Expiration 4/30/00            4

           Integration of Call Authorization and SignalingOctober 1999



   The originating DCS-Proxy (DP-o) authenticates MTA-o and                                                                                                                      f                                                            o                                                             r                                                              wards the
                                                        
   INVITE message to the proper destination proxy, including the local
   Gate information that will be needed for synchronization in DCS-
   Remote-Gate header.

   When the INVITE message is received at the destination DCS-Proxy
   (DP-d), DP-d strips off and stores the DCS-Remote-Gate information,
   then includes its local gate information in the DCS-Remote-Gate
   header and sends the INVITE message to MTA-d.

   Assuming that the call is not forwarded, MTA-d sends a 200 OK
   response to the initial INVITE, forwarded back to MTA-o through DP-
   d. Included in this response is the final negotiated bandwidth
   requirement for the connection.

   DP-d, upon receiving the 200 OK message from MTA-d, adds its local
   Gate information (which is necessary for synchronization) in the
   DCS-Remote-Gate and forwards the 200 OK message to DP-o. DP-d, now
   having sufficient information regarding the end-points, bandwidth
   and characteristics of the media exchange, sends a Gate-Setup
   message to ER-d.

   When DP-o receives the 200 OK, it has sufficient information
   regarding the end-points, bandwidth and characteristics of the media
   exchange. It initiates a Gate-Setup message to ER-o.

   Before sending the Media stream, MTA-o and MTA-d each commit the
   call by sending a Commit message to their respective Edge Routers.

   ER-o, upon reception of the Commit message checks the admissibility
   for the call and if successful, it returns a Success message and
   sends the Commit-Sync message to ER-d. ER-o starts a Sync-Timer. If
   ER-o does not receive Commit-Sync message from ER-d before the timer
   expires, it releases the Gate.

   Once MTA-o receives the Success message it starts to send the Media
   stream.

   Either party can terminate the call.  A Client that detects an on-
   hook sends a Release message to its ER, and sends a SIP BYE message
   to the remote Client.

   On receipt of a Release message, the ER deletes the Gate and sends a
   Release-Sync message to the corresponding ER.

   When ER receives the Release-Sync message it releases the Gate.


6. Changes to SIP to Support Authorization

   This document extends SIP in support of an authorization scheme in
   which network resources must be authorized and admitted before they

DCS Group    Category Informational - Expiration 4/30/00            5

           Integration of Call Authorization and SignalingOctober 1999


   can be used. The extension defined allows network resources to be
   controlled by the DCS-Proxy.

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in RFC-2234 [4].


6.1 SIP Header Extensions

6.1.1 DCS-Local-Gate

   The DCS-Local-Gate general header conveys an identifier of the local
   Gate to a SIP Client.  This information is used for authorizing the
   Media Stream.

        Dcs-Local-Gate = "Dcs-Local-Gate" ":" [hostport "/"]
                                Local-Gate-ID

        Local-Gate-ID   = 1*alphanum

6.1.2 DCS-Remote-Gate

   The DCS-Remote-Gate general header is used between DCS-Proxies, it
   conveys the location of the remote gate, identity of the gate, and
   the security key to be used in gate coordination messages.

        Dcs-Remote-Gate = "Dcs-Remote-Gate" ":" Gate-Location "/"
                        Remote-Gate-ID [";" Gate-Key ";" Gate-
                        CipherSuite]

        Gate-Location   = hostport

        Remote-Gate-ID  = 1*alphanum

        Gate-Key        = 1*alphanum

        Gate-CipherSuite= token


6.2 SIP Profile

   This section defines a SIP [RFC 2543] profile for usage in DCS
   compatible systems from the point of view of Authorizing Calls.

6.2.1. Originating Client

   The SIP messaging that involves destination changes and resource
   increases must be authorized and these messages MUST be sent through
   the originating DCS-Proxy.

   The DCS-Local-Gate header, containing Local-Gate-ID information, is
   included in the 200 OK message sent by the DCS-Proxy. Upon reception


DCS Group    Category Informational - Expiration 4/30/00            6

           Integration of Call Authorization and SignalingOctober 1999


   of Gate information in the DCS-Local-Gate information the
   originating client MUST store the information.

   The Client MUST send a Commit message to the Gate before it starts
   to utilize the network QoS. The Client MUST include in the commit
   message the value of Gate-ID.

   The Client MUST Release resources whenever the Media Stream is
   concluded. The Release message MUST contain sufficient information
   needed to resolve which Gate is released.

6.2.2. Destination Client

   The SIP messaging that involves destination changes and resource
   increases must be authorized and these messages MUST be sent through
   the originating DCS-Proxy.

   The destination Client receives the DCS-Local-Gate in the INVITE
   message from destination DCS-Proxy. The Gate information included
   MUST be stored.

   The Client MUST send a Commit message to the Gate before it starts
   to send the Media Stream. The Client MUST include Gate-ID in the
   Commit message.

   The Client MUST send a Release message including sufficient
   information needed to resolve which Gate is released.

6.2.3. Originating DP

   When an INVITE is received, the originating DP MUST insert its Gate
   information into the DCS-Remote-Gate header and then MUST forward
   the INVITE to the proper destination.

   When 200 OK is received with DCS-Remote-Gate header the DP MUST
   strip and store the information in persistent storage and MUST not
   forward this information to MTA-o

   The DP MUST construct and send a Gate-Setup message to ER-o
   containing information regarding bandwidth and end-points.

   Originating DP MUST include the Gate information in the DCS-Local-
   Gate header of 200 OK message and then MUST send it to the
   originating MTA.

6.2.4. Destination DP

   When an INVITE is received with DCS-Remote-Gate header, the
   destination DP MUST store the information and MUST not forward this
   information to MTA-o.

   The destination DP MUST include in its INVITE message its local Gate
   information in DCS-Local-Gate header and send it to MTA-d.

DCS Group    Category Informational - Expiration 4/30/00            7

           Integration of Call Authorization and SignalingOctober 1999



   The DP MUST construct and send a Gate-Setup message to ER-d
   containing information regarding bandwidth and end-points.

   When the 200 OK response to this INVITE is received from MTA-d, the
   DP MUST insert its Gate information using the DCS-Remote-Gate header
   and then MUST forward the 200 OK to the proper destination.


7. Edge Router Functionality

   When Gate-Setup message is received from DP the ER MUST store the
   contents to be used for authorization.

   Upon reception of a Commit Message the ER MUST check the
   authorization. If successful the ER MUST return Success, else it
   MUST return Failure. At the same time, the ER MUST send the Commit-
   Sync message to the remote ER and start Sync-Timer. If it does not
   receive the respective Commit-Sync from the remote ER before the
   Sync-Timer expires, it MUST delete the Gate opened.

   When a Release message is received, the ER MUST delete the Gate and
   send Release-Sync message to the remote ER.

   When a Release-Sync is received the ER MUST delete the Gate.


8. 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 Gate concept the service provider can control the number
   of flows, the amount of bandwidth and even the end-point reached
   making the IP Telephony system dependable even in the existence of
   scarce resources.


9. Security Considerations

   Gate coordination messages sent between Edge Routers might easily be
   forged, and therefore must be sent encrypted using Gate-Key using
   the Gate-ChipherSuite.


10. References

   1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.




DCS Group    Category Informational - Expiration 4/30/00            8

           Integration of Call Authorization and SignalingOctober 1999



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

   3  DCS Group, "Architectural Considerations for Providing Carrier
      Class Telephony Services Utilizing SIP-based Distributed Call
      Control Mechanisms", draft-dcsgroup-sip-arch-01.txt, October
      1999.

   4  Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
      Specifications: ABNF", RFC 2234, Internet Mail Consortium and
      Demon Internet Ltd., November 1997


11.    Acknowledgments

   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, General Instruments; Doug
   Newlin, Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay
   Networks; Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael
   Ramalho, Cisco; and Chuck Kalmanek, Doug Nortz, John Lawser, James
   Cheng, Tung-Hai Hsiao, and Partho Mishra, AT&T.


12. Author's Addresses

   Bill Marshall
   AT&T
   Florham Park, NJ  07932
   Email: wtm@research.att.com

   K. K. Ramakrishnan
   AT&T
   Florham Park, NJ  07932
   Email: kkrama@research.att.com

   Ed Miller
   CableLabs
   Louisville, CO  80027
   Email: E.Miller@Cablelabs.com

   Glenn Russell
   CableLabs
   Louisville, CO  80027
   Email: G.Russell@Cablelabs.com

   Burcak Beser
   3Com
   Rolling Meadows, IL  60008

DCS Group    Category Informational - Expiration 4/30/00            9

           Integration of Call Authorization and SignalingOctober 1999


   Email: Burcak_Beser@3com.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
   Acton, MA  01720
   Email: oran@cisco.com

   John Pickens
   Com21
   San Jose, CA
   Email: jpickens@com21.com

   Poornima Lalwaney
   General Instrument
   San Diego, CA  92121
   Email: plalwaney@gi.com

   Jon Fellows
   General Instrument
   San Diego, CA  92121
   Email: jfellows@gi.com

   Doc Evans
   Lucent Cable Communications
   Westminster, CO  30120
   Email: n7dr@lucent.com

   Keith Kelly
   NetSpeak
   Boca Raton, FL  33587
   Email: keith@netspeak.com

   Flemming Andreasen
   Telcordia
   Piscataway, NJ
   Email: fandreas@telcordia.com








DCS Group    Category Informational - Expiration 4/30/00           10

           Integration of Call Authorization and SignalingOctober 1999



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 , and expires April 30, 2000.




























DCS Group    Category Informational - Expiration 4/30/00           11