One document matched: draft-dcsgroup-sip-call-auth-00.txt
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
| PAFTECH AB 2003-2026 | 2026-04-24 02:45:25 |