MMUSIC Working Group W. Marshall Internet Draft K. Ramakrishnan Document: <draft-dcsgroup-mmusic-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 June, 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, 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 12/31/99 1 Integration of Call Authorization and Signaling June 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 <draft- dcsgroup-mmusic-call-auth-00.txt>, and expires December 31, 1999. 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 [1]. 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 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 [2]: 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 12/31/99 2 Integration of Call Authorization and Signaling June 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 (GateID) in the response from the ER. The DCS-Proxy uses this GateID 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 GateID 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 12/31/99 3 Integration of Call Authorization and Signaling June 1999 MTA-o MTA-t | DP-o DP-t | | INVITE | INVITE | | |------------------->|-------------->| INVITE+ | | | | Gate-Location | | | |---------------------->| | | | | | | | ER-t | | | | | | | ER-o | | | | | | | |Gate-Setup | | | |Gate-Setup | |-------------->| | | |<--------------| | | | | | | | | | | | | | | | | | | | | | | 200 OK + | | | | | Gate-Location | 200 OK | 200 OK / | |<-------------------|<--------------|<----------------------| | | 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 12/31/99 4 Integration of Call Authorization and Signaling June 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-Location information that will be needed for synchronization. When the INVITE message is received at the destination DCS-Proxy (DP-t), DP-t strips off and stores the Originating Gate-Location information, then includes terminating gate information in the INVITE message and sends the INVITE message to MTA-t. Assuming that the call is not forwarded, MTA-t sends a 200 OK response to the initial INVITE, forwarded back to MTA-o through DP- t. Included in this response is the final negotiated bandwidth requirement for the connection. DP-t, upon receiving the 200 OK message from MTA-t, adds the local Gate-Location information (which is necessary for synchronization) and forwards the 200 OK message to DP-o. DP-t, now having sufficient information regarding the end-points, bandwidth and characteristics of the media exchange, sends a Gate-Setup message to ER-t. 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-t 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-t. ER-o starts a Sync-Timer. If ER-o does not receive Commit-Sync message from ER-t 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 can be used. The extension defined allows network resources to be controlled by the DCS-Proxy. DCS Group Category Informational - Expiration 12/31/99 5 Integration of Call Authorization and Signaling June 1999 The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [3]. 6.1 SIP Header Extension: GATE-LOCATION The Gate-location general header conveys the location and identifier of the local ER to a SIP Client. This information is used for authorizing the Media Stream. GATE-LOCATION = "GateLocation" ":" hostport "/" Gate-ID Gate-ID = 1*alphanum 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 INVITE messages that involve destination changes and resource increases must be authorized and these messages must be sent through the DCS-Proxy. The Client must send a Commit message to the Gate before it starts to utilize the network QoS. The Client MUST send the Commit message to the ER defined by the hostport, and MUST include in the message the value of GateID. The GateLocation header, containing Hostport and GateID information, is included in the 200 OK message sent by the DCS-Proxy. The Client MUST Release resources whenever the Media Stream is concluded. 6.2.2. Destination Client The destination Client receives the GateLocation, Hostport and GateID information included in the INVITE message, and it must store the information. The Client MUST send a Commit message to the Gate before it starts to send the Media Stream. The Client MUST send the Commit message to the ER defined by the GateLocation:Hostport and MUST also include GateID in the message. The Client MUST send a Release message whenever the Media Stream is concluded. 6.2.3. Originating DP When an INVITE is received, the DP MUST insert its local Gate- Location header and then MUST forward the INVITE to the proper destination. DCS Group Category Informational - Expiration 12/31/99 6 Integration of Call Authorization and Signaling June 1999 When 200 OK is received with remote Gate-Location information the DP MUST strip and store the information in persistent storage. DP MUST construct and send a Gate-Setup message containing information regarding bandwidth and end-points. DP MUST include the GateID information in the 200 OK message and then MUST send it to the originating MTA. 6.2.4. Destination DP When an INVITE is received with remote Gate-Location information, the DP MUST save the Gate-Location information and not include this information in the message forwarded on to MTA-t. When the 200 OK response to this INVITE is received, the DP MUST insert its local Gate-Location information using the Gate-Location header and then MUST forward the 200 OK to the proper destination. The DP MUST then construct and send a Gate-Setup message containing information regarding bandwidth and end-points to ER-t. 7. Edge Router Functionality Upon reception of a Commit Message the ER MUST check the authorization status. 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 a timer. If it does not receive the respective Commit-Sync from the remote ER before the timer expires, it MUST delete the Gate just 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 a shared key. 10. References DCS Group Category Informational - Expiration 12/31/99 7 Integration of Call Authorization and Signaling June 1999 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 2 DCS Group, "Architectural Considerations for Providing Carrier Class Telephony Services Utilizing SIP-based Distributed Call Control Mechanisms", draft-dcsgroup-mmusic-arch-00.txt, June 1999. 3 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 Guckle, Cisco; and Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, 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 DCS Group Category Informational - Expiration 12/31/99 8 Integration of Call Authorization and Signaling June 1999 Email: G.Russell@Cablelabs.com Burcak Beser 3Com Rolling Meadows, IL 60008 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 12/31/99 9 Integration of Call Authorization and Signaling June 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 <draft-dcsgroup-mmmusic-call- auth-00.txt>, and expires December 31, 1999. DCS Group Category Informational - Expiration 12/31/99 10