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 <draft- dcsgroup-sip-call-auth-01.txt>, 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 <draft-dcsgroup-sip-call-auth- 01.txt>, and expires April 30, 2000. DCS Group Category Informational - Expiration 4/30/00 11