One document matched: draft-dcsgroup-sip-call-auth-01.txt
Differences from draft-dcsgroup-sip-call-auth-00.txt
SIP Working Group W. Marshall
Internet Draft K. Ramakrishnan
Document: <draft-dcsgroup-sip-call-auth-01.txt> AT&T
Category: Informational
E. Miller
G. Russell
CableLabs
B. Beser
M. Mannette
K. Steinbrenner
3Com
D. Oran
F. Andreasen
Cisco
J. Pickens
Com21
P. Lalwaney
J. Fellows
Motorola
D. Evans
Secure Cable Solutions
K. Kelly
NetSpeak
March, 2000
SIP Extensions for Media Authorization
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."
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.
DCS Group Category Informational - Expiration 9/30/00 1
SIP Extensions for Media Authorization March 2000
The distribution of this memo is unlimited. It is filed as <draft-
dcsgroup-sip-call-auth-01.txt>, and expires September 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. 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 SIP Clients which are considered untrusted, and SIP Proxy
Agents which authorizes the call that is initiated by the SIP Client.
The Sip Proxy Agent authorizes the Media data flow to/from the SIP Client
and returns to the Client a Media-Authorization-Token, which is to be
used for authorization when bandwidth is requested for the data-stream.
When the Client 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 client an Authorization-Token
which is to be used for bandwidth requests. The extension defined allows
network resources to be authorized by the SIP-Proxy.
The following syntax specification uses the augmented Backus-Naur Form
(BNF) as described in RFC-2234 [3].
DCS Group Category Informational - Expiration 9/30/00 2
SIP Extensions for Media Authorization March 2000
5.1 SIP Header Extension
The Media-Auth-Token general header conveys an identifier of the local
Gate to a SIP Client. This information is used for authorizing the Media
Stream.
Media-Auth = "Media- Authorization" ":"
Media-Authorization-Token
Media-Authorization-Token = 1*hex
5.2 SIP Procedures
This section defines a SIP [4] profile for usage in DCS 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. Originating Client (UAC)
The Media-Auth-Token, contained in the Media-Authorization header, is
included in the first response message sent by the SIP-Proxy to the UAC.
The Client SHOULD use the Media-Auth-Token when requesting bandwidth for
Media data stream during initiation and retaining of the bandwidth.
5.2.2. Destination Server (UAS)
The Destination Server receives the Media-Auth-Token in the INVITE
message from SIP-Proxy. The Media-Authorization-Token information
included MUST be stored.
The Server SHOULD use the Media-Auth-Token when requesting bandwidth for
Media data stream during initiation and retaining of the bandwidth.
5.2.3. Originating Proxy Behavior
The Originating Proxy authenticates the caller, and verifies the caller
is authorized to receive the requested level of QoS. In cooperation with
a policy-decision-point, they generate a Media-Auth-Token that contains
sufficient information for the originating client to get the authorized
bandwidth for the media streams.
The Originating Proxy MUST insert the Media-Authorization header in the
response message that it sends to MTA-o.
5.2.4. Destination Proxy Behavior
DCS Group Category Informational - Expiration 9/30/00 3
SIP Extensions for Media Authorization March 2000
The Destination Proxy authenticates the called party, and verifies the
called party is authorized to receive the requested level of QoS. In
cooperation with a policy-decision-point, they generate a Media-Auth-
Token that contains sufficient information for the destination servier to
get the authorized bandwidth for the media streams.
The Destination Proxy MUST insert the Media-Authorization header in the
INVITE message that it sends to MTA-d.
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 [5].
6.1.1. Originating Client Side
Figure 1 presents a high-level overview of a basic MTA-to-MTA call flow
with Media Authorization from the viewpoint of Originating SIP Client. It
is assumed that the SIP-Proxy has a previously established authentication
relationship with the MTA.
When a user goes off-hook and dials a telephone number, the originating
SIP Client (MTA-o) collects the dialed digits and sends the initial
INVITE message to its SIP-Proxy.
The originating SIP-Proxy (DP-o) authenticates MTA-o and f o r wards the
INVITE message to the proper destination proxy.
Assuming that the call is not forwarded, the other end-point sends a 183
response to the initial INVITE, forwarded back to DP-o. Included in this
response is the negotiated bandwidth requirement for the connection.
When DP-o receives the 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.
The PDP-o stores the authorized Media description in its local store
generates a Authorization-Token that points to this description and
returns the Authorization-Token to DP-o.
DCS Group Category Informational - Expiration 9/30/00 4
SIP Extensions for Media Authorization March 2000
MTA-o ER-o PDP-o DP-o
| Invite | | | Client Authentication
|------------------------------------------->| and Call Authorization
| | | | Invite
| | | |-------------->
| | | | 180/3
| | | Auth. Profile |<--------------
| | |<--------------|
| | | Auth. Token |
| | |-------------->| Auth. Token put into
| | | 180/3 | Media-Authorization header
|<-------------------------------------------| extension.
|Copies the RSVP policy object |
|from the Media-Authorization |
| RSVP-PATHo | | |
|----------->| REQ | |
| |-------------->| Using the Auth-Token and Authorized
| | DEC | Profile that is set by the SIP Proxy
| |<--------------| the PDP makes the decision
| | | | RSVP-PATHo
| |------------------------------------------------>
| | | | RSVP-PATHt
|<--------------------------------------------------------------
|Copies the RSVP policy object |
|from the Media-Authorization |
| RSVP-RESVt | | |
|------------>| REQ | |
| |-------------->| Using the Auth-Token and Authorized
| | DEC | Profile that is set by the SIP Proxy
| |<--------------| the PDP makes the decision
| | | | RSVP-RESVt
| |--------------------------------------------------->
| | | | RSVP-RESVo
|<----------------------------------------------------------------
| | | | RSVP-RESVCONFo
|---------------------------------------------------------------->
| | | | RSVP-RESVCONFt
|<----------------------------------------------------------------
| | | | 200 OK
|<--------------------------------------------|<------------------
| | | | MEDIA
|<===============================================================>
| | | | ACK
|---------------------------------------------------------------->
Figure 1
DCS Group Category Informational - Expiration 9/30/00 5
SIP Extensions for Media Authorization March 2000
The DP-o includes the Authorization-Token in the Media-Auth-Token header
extension that its including into the 183 message.
MTA-o upon reception stores the Media-Authorization-Token inside the
Media-Auth-Token header extension.
Before sending the Media stream, MTA-o and MTA-t each request bandwidth
using RSVP-PATH message which 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.
ER-o, upon reception of the RSVP-PATHo message checks the authorization
through PDP-o COPS message exchange. The PDP-o checks the authorization
using the stored authorized Media description that was linked to
Authorization-Token that it returned to DP-o. If authorization is
successful PDP-o returns install Decision.
ER-o checks the admissibility for the call and if admission succeeds, it
forwards the RSVP-PATHo message.
Once MTA-o receives the RSVP-PATH-t message it sends RSVP-RESVt message
to reserve the bandwidth.
ER-o, upon reception of the RSVP-RESVt message checks the authorization
through PDP-o COPS message exchange. The PDP-o checks the authorization
using the stored authorized Media description that was linked to
Authorization-Token that it returned to DP-o. If authorization is
successful PDP-o returns install Decision.
ER-o checks the admissibility for the call and if admission succeeds, it
forwards the RSVP- RESVt message.
Upon reception of RSVP-RESVo message the MTA-o sends RSVP-RESVCONFo
message to indicate that the reservation completed for one direction.
Upon reception of both RSVP-RESVCONFt and 200OK the MTA-o returns ACK
message.
6.1.2. Terminating Client Side
Figure 2 presents a high-level overview of a basic MTA-to-MTA call flow
with Media Authorization from the viewpoint of Terminating SIP Client
(MTA-t). It is assumed that the SIP-Proxy has a previously established
authentication relationship with the MTA.
The destination SIP-Proxy (DP-t) upon reception of the Invite message.
Since it has sufficient information regarding the end-points, bandwidth
and characteristics of the media exchange. It initiates a Policy-Setup
message to PDP-t.
DCS Group Category Informational - Expiration 9/30/00 6
SIP Extensions for Media Authorization March 2000
MTA-t ER-t PDP-t DP-t
| | | | Invite
| | | |<--------------
| | | | Proxy Authentication
| | | Auth. Profile | and Call Authorization
| | |<--------------|
| | | Auth. Token |
| | |-------------->| Auth. Token put into
| | | Invite | Media-Authorization header
|<------------------------------------------| extension
| 180/3 | | |
|------------------------------------------>| 180/3
|Copies the RSVP policy object |-------------->
|from the Media-Authorization |
| RSVP-PATHt| | |
|---------->| REQ | |
| |-------------->| Using the Auth-Token and Authorized
| | DEC | Profile that is set by the SIP Proxy
| |<--------------| the PDP makes the decision
| | | | RSVP-PATHt
| |-------------------------------------------------->
| | | | RSVP-PATHo
|<--------------------------------------------------------------
|Copies the RSVP policy object |
|from the Media-Authorization |
| RSVP-RESVo| | |
|---------->| | |
| | REQ | |
| |-------------->| Using the Auth-Token and Authorized
| | DEC | Profile that is set by the SIP Proxy
| |<--------------| the PDP makes the decision
| | | | RSVP-RESVo
| |--------------------------------------------------->
| | | | RSVP-RESVt
|<---------------------------------------------------------------
| | | | RSVP-RESVCONFt
|--------------------------------------------------------------->
| | | | RSVP-RESVCONFo
|<---------------------------------------------------------------
| | | | 200 OK
|-----------------------------------------> |------------------->
| | | | ACK
|<----------------------------------------------------------------
Figure 2
DCS Group Category Informational - Expiration 9/30/00 7
SIP Extensions for Media Authorization March 2000
The PDP-t stores the authorized Media description in its local store
generates a Authorization-Token that points to this description and
returns the Authorization-Token to DP-t.
Assuming that the call is not forwarded, the MTA-t sends a 183 response
to the initial INVITE, which is forwarded back to MTA-o. At the same time
MTA-t sends 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.
ER-t, upon reception of the RSVP-PATHt message checks the authorization
through PDP-t COPS message exchange. The PDP-t checks the authorization
using the stored authorized Media description that was linked to
Authorization-Token that it returned to DP-t. If authorization is
successful PDP-t returns install Decision.
ER-t checks the admissibility for the call and if admission succeeds, it
forwards the RSVP-PATHd message.
Once MTA-t receives the RSVP-PATHo message it sends RSVP-RESVo message to
reserve the bandwidth.
ER-t, upon reception of the RSVP-RESVo message checks the authorization
through PDP-t COPS message exchange. The PDP-t checks the authorization
using the stored authorized Media description that was linked to
Authorization-Token that it returned to DP-t. If authorization is
successful PDP-t returns install Decision.
ER-t checks the admissibility for the call and if admission succeeds, it
forwards the RSVP- RESVo message.
Upon reception of RSVP-RESVd message the MTA-t sends RSVP-RESVCONFt
message to indicate that the reservation completed for one direction.
Upon reception of both RSVP-RESVCONFo and 200OK the MTA-t returns ACK
message.
6.2. Requesting Bandwidth via DOCSIS MAC messaging
The DOCSIS MAC layer QoS Set-Up the call flows are different in the sense
that the Authorization token is a simple 32bit number. And DSA-REQ, DSA-
RSP, and DSA-ACK are layer 2 messages that are specific to and optimized
for Cable environment which simplifies/reduces delays for the embedded
client implementation.
DCS Group Category Informational - Expiration 9/30/00 8
SIP Extensions for Media Authorization March 2000
MTA-o ER/CMTS-o DP-o
| Invite | |
|------------------------------------------->| Client Authentication
| | |and Call Authorization
| | |
| | | Invite
| | |----------->
| | |
| | | 180/3 OK
| | |<------------
| | |
| | Gate-Setup |
| |<--------------------- |
| | Gate-Setup-Ack |
| |---------------------> |
| | | GateID put into
| | | Media-Authorization header
| | | extensiom
| | 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. Originating Client Side
Figure 3 presents a high-level overview of a basic MTA-to-MTA call flow
with Media Authorization from the viewpoint of Originating SIP Client
(MTA-o). It is assumed that the SIP-Proxy has a previously established
authentication relationship with the MTA.
When a user goes off-hook and dials a telephone number, the originating
SIP Client (MTA-o) collects the dialed digits and sends the initial
INVITE message to its SIP-Proxy.
The originating SIP-Proxy (DP-o) authenticates MTA-o and forwards the
INVITE message to the proper destination proxy.
DCS Group Category Informational - Expiration 9/30/00 9
SIP Extensions for Media Authorization March 2000
Assuming that the call is not forwarded, the other end-point sends a 183
response to the initial INVITE, forwarded back to DP-o. Included in this
response is the negotiated bandwidth requirement for the connection.
When DP-o 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/CMTS-t containing Media data-stream
description and bandwidth characteristics. The ER/CMTS-t returns a 32 bit
index value that inside ER/CMTS-t points to Media definition that DP-o
send out.
MTA-t sends DSA-REQ message asking for bandwidth which includes the 32
bit index value.
ER/CMTS-t, upon reception of the RSA-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 MTA-o via DSA-ACK message.
Upon reception of 200OK the MTA-t returns ACK message.
6.2.2. Terminating Client Side
Figure 4 presents a high-level overview of a basic MTA-to-MTA call flow
with Media Authorization from the viewpoint of Terminating SIP Client
(MTA-t). It is assumed that the SIP-Proxy has a previously established
authentication relationship with the MTA.
When DP-t receives the Invite, it has sufficient information regarding
the end-points, bandwidth and characteristics of the media exchange. It
sends a Gate-Setup message to ER/CMTS-t containing Media data-stream
description and bandwidth characteristics. The ER/CMTS-t returns a 32 bit
index value that inside ER/CMTS-t points to Media definition that DP-t
send out.
The DP-t includes the 32 bit index value in the Media-Auth-Token header
extension that its including into the Invite message.
The MTA-t sends a 183 response to the initial INVITE, which is forwarded
back to MTA-o. At the same time MTA-t sends DSA-REQ message asking for
bandwidth which includes the 32 bit index value.
ER/CMTS-t, upon reception of the RSA-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 MTA-o via DSA-ACK message. Upon
reception of DSA-RSP the MTA-t returns ACK message.
DCS Group Category Informational - Expiration 9/30/00 10
SIP Extensions for Media Authorization March 2000
MTA-t ER/CMTS-t DP-t
| | |
| | | Invite
| | |<-----------
| | | Proxy Authentication
| | | and Call Authorization
| | Gate-Setup |
| |<----------------------|
| | Gate-Setup-Ack |
| |---------------------->|
| | | GateID put into
| | | Media-Authorization header
| | | extension
| Invite | |
|<-------------------------------------------|
| | |
| | 180/3 |
|------------------------------------------->|
| | | 180/3
| | |------------>
|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 | |
|------------------->| |
| | |
| | 200 OK |
|------------------------------------------->|
| | | 200 OK
| | |------------>
Figure 4
DCS Group Category Informational - Expiration 9/30/00 11
SIP Extensions for Media Authorization March 2000
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 proxy to a UAC/UAS MUST be
protected from eavesdropping, through a mechanism such as IPSec.
9. 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 RFC 2210, The Use of RSVP with IETF Integrated Services by J.
Wroclawski, September 1997.
10. 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, 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.
DCS Group Category Informational - Expiration 9/30/00 12
SIP Extensions for Media Authorization March 2000
13. 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
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
Flemming Andreasen
Cisco
Edison, NJ
Email: fandreas@cisco.com
John Pickens
Com21
San Jose, CA
DCS Group Category Informational - Expiration 9/30/00 13
SIP Extensions for Media Authorization March 2000
Email: jpickens@com21.com
Poornima Lalwaney
Motorola
San Diego, CA 92121
Email: plalwaney@gi.com
Jon Fellows
Motorola
San Diego, CA 92121
Email: jfellows@gi.com
Doc Evans
Secure Cable Solutions
Westminster, CO 30120
Email: drevans@securecable.com
Keith Kelly
NetSpeak
Boca Raton, FL 33587
Email: keith@netspeak.com
DCS Group Category Informational - Expiration 9/30/00 14
SIP Extensions for Media Authorization March 2000
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 September 30, 2000.
DCS Group Category Informational - Expiration 9/30/00 15
| PAFTECH AB 2003-2026 | 2026-04-24 02:44:07 |