idnits 2.17.1 draft-ietf-sip-call-auth-04.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 141 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 205 has weird spacing: '... Where proxy...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 47 looks like a reference -- Missing reference section? '2' on line 103 looks like a reference -- Missing reference section? '3' on line 215 looks like a reference -- Missing reference section? '4' on line 153 looks like a reference -- Missing reference section? '5' on line 202 looks like a reference -- Missing reference section? '6' on line 301 looks like a reference -- Missing reference section? '7' on line 317 looks like a reference -- Missing reference section? '8' on line 341 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIP Working Group W. Marshall 2 Internet Draft AT&T 3 Document: 4 Category: Informational K. Ramakrishnan 5 TeraOptic Networks 7 E. Miller 8 Terayon 10 G. Russell 11 CableLabs 13 B. Beser 14 Juniper Networks 16 M. Mannette 17 K. Steinbrenner 18 3Com 20 D. Oran 21 F. Andreasen 22 Cisco 24 J. Pickens 25 Com21 27 P. Lalwaney 28 Nokia 30 J. Fellows 31 Copper Mountain Networks 33 D. Evans 34 D. R. Evans Consulting 36 K. Kelly 37 NetSpeak 39 February, 2002 41 SIP Extensions for Media Authorization 43 Status of this Memo 45 This document is an Internet-Draft and is in full conformance with all 46 provisions of Section 10 of RFC 2026 [1]. 48 Internet-Drafts are working documents of the Internet Engineering Task 49 Force (IETF), its areas, and its working groups. Note that other groups 50 may also distribute working documents as Internet-Drafts. Internet-Drafts 51 are draft documents valid for a maximum of six months and may be updated, 52 replaced, or obsoleted by other documents at any time. It is 54 SIP Working Group Informational - Expires 8/31/02 1 55 SIP Extensions for Media Authorization February 2002 57 inappropriate to use Internet-Drafts as reference material or to cite 58 them other than as "work in progress." 60 The list of current Internet-Drafts can be accessed at 61 http://www.ietf.org/ietf/1id-abstracts.txt 63 The list of Internet-Draft Shadow Directories can be accessed at 64 http://www.ietf.org/shadow.html. 66 1. Abstract 68 This document describes the need for QoS and media authorization and 69 defines a SIP extension that can be used to integrate QoS admission 70 control with call signaling and help guard against denial of service 71 attacks. The use of this extension is only applicable in administrative 72 domains, or among federations of administrative domains with previously 73 agreed-upon policies, where both the SIP proxy authorizing the QoS, and 74 the policy control of the underlying network providing the QoS belong to 75 that administrative domain or federation of domains. 77 2. Scope of Applicability 79 This document defines a SIP extension that can be used to integrate QoS 80 admission control with call signaling and help guard against denial of 81 service attacks. The use of this extension is only applicable in 82 administrative domains, or among federations of administrative domains 83 with previously agreed-upon policies, where both the SIP proxy 84 authorizing the QoS, and the policy control of the underlying network 85 providing the QoS belong to that administrative domain or federation of 86 domains. Furthermore, the mechanism is generally incompatible with end- 87 to-end encryption of message bodies that describe media sessions. 89 This is in contrast with general Internet principles which separate data 90 transport from applications, and the solution described in this document 91 is thus not applicable to the Internet at large. Despite these 92 limitations, there are sufficiently useful specialized deployments that 93 meet the assumptions described above, and can accept the limitations that 94 result, to warrant publication of this mechanism. An example deployment 95 would be a closed network which emulates a traditional circuit switched 96 telephone network. 98 3. Conventions used in this document 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [2]. 104 4. Background and Motivation 106 Current IP telephony systems assume a perfect world in which there is 107 either unlimited amount of bandwidth or network layer Quality of Service 108 (QoS) is provided without any kind of policy control. However the reality 109 is that end-to-end bandwidth is not unlimited and uncontrolled access to 110 QoS in general is unlikely. The primary reason for this is that QoS 112 SIP Working Group Informational - Expires 8/31/02 2 113 SIP Extensions for Media Authorization February 2002 115 provides preferential treatment of one flow at the expense of another. 116 Consequently, it is important to have policy control over whether a given 117 flow should have access to QoS. This will not only enable fairness in 118 general, but can also prevent denial of service attacks. 120 In this document, we are concerned with providing QoS for media streams 121 established via the Session Initiation Protocol (SIP) [3]. We assume an 122 architecture that integrates call signaling with media authorization as 123 illustrated in the Figure below. The solid lines (A and B) show 124 interfaces whereas the dotted line (C) illustrates the QoS enabled media 125 flow: 127 +---------+ 128 | Proxy | 129 +--------->| | 130 | +---------+ 131 | ^ 132 A)| B) | 133 | { } 134 | | 135 | v 136 v +------+ 137 +------+ C) | Edge | 138 | UA |........|router|...... 139 +------+ +------+ 141 Figure 1 - Basic Architecture 143 In this architecture, we assume an untrusted SIP UA connected to a QoS 144 enabled network with an edge router acting as a Policy Enforcement Point 145 (PEP) [4]. We furthermore assume that a SIP UA, that wishes to obtain 146 QoS, initiates sessions through a proxy which can interface with the QoS 147 policy control for the data network being used. We will refer to such a 148 proxy as a QoS enabled proxy. We assume that the SIP UA needs to present 149 an authorization token to the network in order to obtain Quality of 150 Service (C). The SIP UA obtains this authorization token via SIP (A) from 151 the QoS enabled proxy by means of an extension SIP header defined in this 152 document. The proxy in turn communicates either directly with the edge 153 router or with a Policy Decision Point (PDP - not shown) [4] in order to 154 obtain a suitable authorization token for the UA. 156 Examples of access data networks where such a QoS enabled proxy could be 157 used include DOCSIS based cable networks and 3rd generation (3G) wireless 158 networks. 160 5. Overview 162 A session, that needs to obtain QoS for the media streams in accordance 163 with our basic architecture described above is performed as follows. 165 SIP Working Group Informational - Expires 8/31/02 3 166 SIP Extensions for Media Authorization February 2002 168 The SIP UA sends an INVITE to the QoS enabled proxy which for each 169 resulting dialog includes a media authorization token in all unreliable 170 provisional responses (except 100), the first reliable 1xx or 2xx 171 response, and all retransmissions of that reliable response for the 172 dialog. When the UA requests QoS, it includes the media authorization 173 token with the resource reservation. 175 A SIP UA may also receive an INVITE from its QoS enabled proxy which 176 includes a media authorization token. In that case, when the UA requests 177 QoS, it includes the media authorization token with the resource 178 reservation. 180 6. Changes to SIP to Support Media Authorization 182 This document defines a private SIP header extension to support a media 183 authorization scheme. In this architecture a QoS enabled SIP proxy 184 supplies the UA with an authorization token which is to be used in QoS 185 requests. The extension defined allows network QoS resources to be 186 authorized by the QoS enabled SIP proxy. 188 6.1 SIP Header Extension 190 A new P-Media-Authorization general header field is defined. The Media- 191 Auth header field contains a media authorization token which is to be 192 included in subsequent resource reservations for the media flows 193 associated with the session. The media authorization token is used for 194 authorizing QoS for the media stream(s). The P-Media-Authorization header 195 field is described by the following ABNF [5]: 197 P-Media-Authorization = "P-Media-Authorization" ":" 198 P-Media-Authorization-Token 200 P-Media-Authorization-Token = 1*HEXDIG 202 Table 1 below is an extension of tables 2 and 3 in [5] for the new header 203 field defined here: 205 Where proxy ACK BYE CAN INV OPT REG 206 P-Media-Authorization ad - - - o - - 208 Table 1: Summary of header fields. 210 The P-Media-Authorization header field can be used with the INVITE method 211 as well as any response to it. 213 6.2 SIP Procedures 215 This section defines the SIP [3] procedures for usage in media 216 authorization compatible systems from the point of view of authorizing 217 QoS. 219 SIP Working Group Informational - Expires 8/31/02 4 220 SIP Extensions for Media Authorization February 2002 222 6.2.1. User Agent Client (UAC) 224 The initial SIP INVITE message, mid-call messages that result in network 225 QoS resource changes, and mid-call changes in call destination should be 226 authorized. These SIP messages are sent through the QoS enabled proxies 227 to receive this authorization. In order to authorize QoS, the QoS enabled 228 SIP proxy MAY need to inspect message bodies that describe the media 229 streams, e.g. SDP, and hence such message bodies SHOULD NOT be encrypted 230 end-to-end. 232 The P-Media-Authorization-Token, which is contained in the P-Media- 233 Authorization header, is included for each dialog in all unreliable 234 provisional responses (except 100), the first reliable 1xx or 2xx 235 response, and all retransmissions of that reliable response for the 236 dialog sent by the QoS enabled SIP proxy to the UAC. 238 The UAC SHOULD use all the P-Media-Authorization-Token(s) from the most 239 recent request/response that contained the P-Media-Authorization header 240 when requesting QoS for the associated media stream(s). This applies both 241 to the initial and subsequent refresh reservation messages. The UAC 242 converts the string of hex digits into binary, and utilizes the result as 243 a Policy-Element as defined in RFC 2750 [6] (including Length and P- 244 Type). This Policy-Element would typically contain the authorizing entity 245 and credentials, and be used in an RSVP request for media data stream QoS 246 resources. 248 6.2.2. User Agent Server (UAS) 250 The User Agent Server receives the P-Media-Authorization-Token in an 251 INVITE (or other) message from the QoS enabled SIP proxy. If the response 252 contains a message body that describes media streams for which the UA 253 desires QoS, said message body SHOULD NOT be end-to-end encrypted. 255 The UAS SHOULD use all the P-Media-Authorization-Token(s) from the most 256 recent request/response that contained the P-Media-Authorization header 257 when requesting QoS for the associated media stream(s). This applies both 258 to the initial and subsequent refresh reservation messages. The UAS 259 converts the string of hex digits into binary, and utilizes the result as 260 a Policy-Element as defined in RFC 2750 [6] (including Length and P- 261 Type). This Policy-Element would typically contain the authorizing entity 262 and credentials, and be used in an RSVP request for media data stream 263 resources. 265 6.2.3. Originating Proxy (OP) 267 When the originating QoS enabled proxy (OP) receives an INVITE (or other) 268 message from the UAC, the proxy authenticates the caller, and verifies 269 that the caller is authorized to receive QoS. 271 In cooperation with an originating Policy Decision Point (PDP-o), the OP 272 obtains and/or generates a media authorization token that contains 273 sufficient information for the UAC to get the authorized QoS for the 274 media streams. The media authorization token is formatted as a Policy- 275 Element, as defined in RFC 2750 [6], and then converted to a string of 277 SIP Working Group Informational - Expires 8/31/02 5 278 SIP Extensions for Media Authorization February 2002 280 hex digits to form a P-Media-Authorization-Token. The proxy MAY inspect 281 message bodies that describe the media streams, e.g. SDP, in both 282 requests and responses in order to decide what QoS to authorize. 284 For each dialog that results from the INVITE (or other) message received 285 from the UAC, the originating proxy MUST add a P-Media-Authorization 286 header with the P-Media-Authorization-Token in all unreliable provisional 287 responses (except 100), the first reliable 1xx or 2xx response, and all 288 retransmissions of that reliable response the proxy sends to the UAC, if 289 that response may result in network QoS changes. A response with an SDP 290 may result in such changes. 292 6.2.4. Destination Proxy (DP) 294 The Destination QoS Enabled Proxy (DP) verifies that the called party is 295 authorized to receive QoS. 297 In cooperation with a terminating Policy Decision Point (PDP-t), the DP 298 obtains and/or generates a media authorization token that contains 299 sufficient information for the UAS to get the authorized QoS for the 300 media streams. The media authorization token is formatted as a Policy- 301 Element, as defined in RFC 2750 [6], and then converted to a string of 302 hex digits to form a P-Media-Authorization-Token. The proxy MAY inspect 303 message bodies that describe the media streams, e.g. SDP, in both 304 requests and responses in order to decide what QoS to authorize. 306 The Destination Proxy MUST add the P-Media-Authorization header with the 307 P-Media-Authorization-Token in the INVITE (or other) request that it 308 sends to the UAS, if that message may result in network QoS changes. A 309 message with an SDP body may result in such changes. 311 7. Examples 313 7.1. Requesting Bandwidth via RSVP messaging 315 Below we provide an example for how the P-Media-Authorization header 316 field can be used in conjunction with the Resource Reservation Protocol 317 (RSVP) [7]. The example assumes that resource management is integrated 318 with SIP signaling and therefore utilizes the 183 Session Progress 319 provisional response, which contains an SDP description of the media 320 flow. 322 7.1.1. User Agent Client Side 324 Figure 2 presents a high-level overview of a basic call flow with media 325 authorization from the viewpoint of the UAC. Some policy interactions 326 have been omitted for brevity. 328 When a user goes off-hook and dials a telephone number, the UAC collects 329 the dialed digits and sends the initial (1)INVITE message to the 330 originating SIP proxy. 332 The originating SIP proxy (OP) authenticates the user/UAC and forwards 333 the (2)INVITE message to the proper SIP proxy. 335 SIP Working Group Informational - Expires 8/31/02 6 336 SIP Extensions for Media Authorization February 2002 338 Assuming the call is not forwarded, the terminating end-point sends a 339 (3)183 response to the initial INVITE via OP. Included in this response 340 is an indication of the negotiated bandwidth requirement for the 341 connection (in the form of an SDP description [8]). 343 When OP receives the (3)183, it has sufficient information regarding the 344 end-points, bandwidth and characteristics of the media exchange. It 345 initiates a Policy-Setup message to PDP-o, (4)AuthProfile. 347 The PDP-o stores the authorized media description in its local store, 348 generates an authorization token that points to this description, and 349 returns the authorization token to the OP, (5)AuthToken. 351 UAC ER-o PDP-o OP 352 |(1)Invite | | | Client Authentication 353 |------------------------------------------->| and Call Authorization 354 | | | | (2)Invite 355 | | | |--------------> 356 | | | | (3)180/3 357 | | |(4)AuthProfile |<-------------- 358 | | |<--------------| 359 | | |(5)AuthToken | 360 | | |-------------->| Auth. Token put into 361 | | |(6)180/3 | P-Media-Authorization 362 |<-------------------------------------------| header extension. 363 |Copies the RSVP policy object | 364 |from the P-Media-Authorization | 365 |(7)RSVP-PATH | | 366 |----------->| (8)REQ | | 367 | |-------------->| Using the Auth-Token and Authorized 368 | | (9)DEC | Profile that is set by the SIP Proxy 369 | |<--------------| the PDP makes the decision 370 | | | |(10)RSVP-PATH 371 | |------------------------------------------------> 372 | | | |(11)RSVP-PATH 373 |<-------------------------------------------------------------- 374 |Copies the RSVP policy object | 375 |from the P-Media-Authorization | 376 |(12)RSVP-RESV | | 377 |----------->| (13)REQ | | 378 | |-------------->| Using the Auth-Token and Authorized 379 | | (14)DEC | Profile that is set by the SIP Proxy 380 | |<--------------| the PDP makes the decision 381 | | | |(15)RSVP-RESV 382 | |---------------------------------------------------> 383 | | | |(16)RSVP-RESV 384 |<---------------------------------------------------------------- 385 | | | | 387 Figure 2 - Media Authorization with RSVP (UAC) 389 SIP Working Group Informational - Expires 8/31/02 7 390 SIP Extensions for Media Authorization February 2002 392 The OP includes the authorization token in the P-Media-Authorization 393 header extension of the (6)183 message. 395 Upon receipt of the (6)183 message, the UAC stores the media 396 authorization token from the P-Media-Authorization header. 398 Before sending any media, the UAC requests QoS by sending an (7)RSVP-PATH 399 message which includes the previously stored P-Media-Authorization-Token 400 as a Policy-Element. 402 ER-o, upon reception of the (7)RSVP-PATH message checks the authorization 403 through a PDP-o COPS message exchange, (8)REQ. PDP-o checks the 404 authorization using the stored authorized media description that was 405 linked to the authorization token it returned to OP. If authorization is 406 successful, PDP-o returns an "install" Decision, (9)DEC. 408 ER-o checks the admissibility for the request and if admission succeeds, 409 it forwards the (10)RSVP-PATH message. 411 Once UAC receives the (11)RSVP-PATH message from UAS it sends the 412 (12)RSVP-RESV message to reserve the network resources. 414 ER-o, upon receiving the (12)RSVP-RESV message checks the authorization 415 through a PDP-o COPS message exchange, (13)REQ. PDP-o checks the 416 authorization using the stored authorized media description that was 417 linked to the authorization token it returned to OP. If authorization is 418 successful PDP-o returns an "install" Decision, (14)DEC. 420 ER-o checks the admissibility for the request and if admission succeeds, 421 it forwards the (15)RSVP-RESV message. 423 Upon receiving the (16)RSVP-RESV message, network resources have been 424 reserved in both directions. 426 7.1.2. User Agent Server Side 428 Figure 3 presents a high-level overview of a call flow with media 429 authorization from the viewpoint of the UAS. Some policy interactions 430 have been omitted for brevity. 432 Since the destination SIP proxy (DP) has sufficient information regarding 433 the endpoints, bandwidth and characteristics of the media exchange, it 434 initiates a Policy-Setup message to the terminating Policy Decision Point 435 (PDP-t) on receipt of the (1)INVITE. 437 SIP Working Group Informational - Expires 8/31/02 8 438 SIP Extensions for Media Authorization February 2002 440 UAS ER-t PDP-t DP 441 | | | | (1)Invite 442 | | | |<-------------- 443 | | | | Proxy Authentication 444 | | | (2)AuthProfile| and Call Authorization 445 | | |<--------------| 446 | | | (3)AuthToken | 447 | | |-------------->| Auth. Token put into 448 | | | (4)Invite | P-Media-Authorization 449 |<------------------------------------------| header extension 450 | (5)180/3 | | | 451 |------------------------------------------>| (6)180/3 452 |Copies the RSVP policy object |--------------> 453 |from the P-Media-Authorization | 454 |(7)RSVP-PATH | | 455 |---------->| (8)REQ | | 456 | |-------------->| Using the Auth-Token and Authorized 457 | | (9)DEC | Profile that is set by the SIP Proxy 458 | |<--------------| the PDP makes the decision 459 | | | |(10)RSVP-PATH 460 | |--------------------------------------------------> 461 | | | |(11)RSVP-PATH 462 |<-------------------------------------------------------------- 463 |Copies the RSVP policy object | 464 |from the P-Media-Authorization | 465 | (12)RSVP-RESV | | 466 |---------->| | | 467 | | (13)REQ | | 468 | |-------------->| Using the Auth-Token and Authorized 469 | | (14)DEC | Profile that is set by the SIP Proxy 470 | |<--------------| the PDP makes the decision 471 | | | |(15)RSVP-RESV 472 | |---------------------------------------------------> 473 | | | |(16)RSVP-RESV 474 |<--------------------------------------------------------------- 475 | | | | 477 Figure 3 - Media Authorization with RSVP (UAS) 479 PDP-t stores the authorized media description in its local store, 480 generates an authorization token that points to this description, and 481 returns the authorization token to DP. The token is placed in the 482 (4)INVITE message and forwarded to the UAS. 484 Assuming that the call is not forwarded, the UAS sends a (5)183 response 485 to the initial INVITE message, which is forwarded back to UAC. At the 486 same time, the UAS sends an (7)RSVP-PATH message which includes the 487 previously stored P-Media-Authorization-Token as a Policy-Element. 489 ER-t, upon receiving the (7)RSVP-PATH message checks the authorization 490 through a PDP-t COPS message exchange. PDP-t checks the authorization 491 using the stored authorized media description that was linked to the 493 SIP Working Group Informational - Expires 8/31/02 9 494 SIP Extensions for Media Authorization February 2002 496 authorization token it returned to DP. If authorization is successful 497 PDP-t returns an "install" Decision, (9)DEC. 499 ER-t checks the admissibility for the call and if admission succeeds, it 500 forwards the (10)RSVP-PATH message. 502 Once the UAS receives the (11)RSVP-PATH message, it sends (12)RSVP-RESV 503 message to reserve the network resources. 505 ER-t, upon reception of the (12)RSVP-RESV message, checks the 506 authorization through a PDP-t COPS message exchange. PDP-t checks the 507 authorization using the stored authorized media description that was 508 linked to the authorization token that it returned to DP. If 509 authorization is successful PDP-t returns an "install" Decision, (14)DEC. 511 ER-t checks the admissibility for the call and if admission succeeds, it 512 forwards the (15)RSVP-RESV message. 514 Upon receiving the (16)RSVP-RESV message, network resources have been 515 reserved in both directions. 517 8. Advantages of the Proposed Approach 519 The use of media authorization makes it possible to control the usage of 520 network resources. This in turn makes IP Telephony more robust against 521 denial of service attacks and various kinds of service frauds. By using 522 the authorization capability, the number of flows, and the amount of 523 network resources reserved can be controlled thereby making the IP 524 Telephony system dependable in the presence of scarce resources. 526 9. Security Considerations 528 Media authorization tokens sent in the P-Media-Authorization header from 529 a QoS enabled proxy to a UA MUST be protected from eavesdropping and 530 tampering. This can for example be done through a mechanism such as IPSec 531 or TLS. However, this will only provide hop-by-hop security. If there is 532 one or more intermediaries, e.g. proxies, between the UA and the QoS 533 enabled proxy, these intermediaries will have access to the P-Media- 534 Authorization header field value thereby compromising confidentiality and 535 integrity. This will enable both theft-of-service and denial-of-service 536 attacks against the UA. Consequently, the P-Media-Authorization header 537 field MUST NOT be available to any untrusted intermediary in clear or 538 without integrity protection. There is currently no mechanism defined in 539 SIP that would satisfy these requirements. Until such a mechanism 540 exists, proxies MUST NOT send P-Media-Authorization headers through 541 untrusted intermediaries. 543 QoS enabled proxies may need to inspect message bodies describing media 544 streams, e.g. SDP. Consequently, such message bodies SHOULD NOT be 545 encrypted. This will in turn prevent end-to-end confidentiality of said 546 message bodies which lowers the overall security possible. 548 SIP Working Group Informational - Expires 8/31/02 10 549 SIP Extensions for Media Authorization February 2002 551 10. IANA Considerations 553 This document defines a new private SIP header for media authorization 554 which is "P-Media-Authorization". 556 11. Notice Regarding Intellectual Property Rights 558 The IETF has been notified of intellectual property rights claimed in 559 regard to some or all of the specification contained in this document. 560 For more information consult the online list of claimed rights. 562 12. References 564 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, 565 RFC 2026, October 1996. 567 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 568 Levels", BCP 14, RFC 2119, March 1997. 570 3 Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, 571 J., Sparks, R., Handley, M., E. Schooler, "SIP: Session Initiation 572 Protocol", Work in Progress, February 21, 2002. 574 4 Yavatkar, R., Pendarakis, D., Guerin, R., "A Framework for Policy- 575 based Admission Control", RFC 2753, January 2000. 577 5 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 578 Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon 579 Internet Ltd., November 1997. 581 6 Herzog, S., RSVP Extensions for Policy Control, RFC 2750, January 582 2000. 584 7 Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 585 2210, September 1997. 587 8 Handley, M., Jacobson, V., "SDP: Session Description Protocol", RFC 588 2327, April, 1998. 590 13. Acknowledgments 592 The Distributed Call Signaling work in the PacketCable project is 593 the work of a large number of people, representing many different 594 companies. The authors would like to recognize and thank the 595 following for their assistance: John Wheeler, Motorola; David 596 Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows, 597 Jay Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin, 598 Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; 599 Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho, 600 Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung- 601 Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent 602 Cable Communications. Dean Willis provided valuable feedback as 603 well. 605 SIP Working Group Informational - Expires 8/31/02 11 606 SIP Extensions for Media Authorization February 2002 608 14. Authors' Addresses 610 Bill Marshall 611 AT&T 612 Florham Park, NJ 07932 613 Email: wtm@research.att.com 615 K. K. Ramakrishnan 616 TeraOptic Networks 617 Summit, NJ 07901 618 Email: kk@teraoptic.com 620 Ed Miller 621 Terayon 622 Louisville, CO 80027 623 Email: edward.miller@terayon.com 625 Glenn Russell 626 CableLabs 627 Louisville, CO 80027 628 Email: G.Russell@Cablelabs.com 630 Burcak Beser 631 Juniper Networks 632 Sunnyvale, CA 633 Email: burcak@juniper.net 635 Mike Mannette 636 3Com 637 Rolling Meadows, IL 60008 638 Email: Michael_Mannette@3com.com 640 Kurt Steinbrenner 641 3Com 642 Rolling Meadows, IL 60008 643 Email: Kurt_Steinbrenner@3com.com 645 Dave Oran 646 Cisco 647 Acton, MA 01720 648 Email: oran@cisco.com 650 Flemming Andreasen 651 Cisco 652 Edison, NJ 653 Email: fandreas@cisco.com 655 John Pickens 656 Com21 657 San Jose, CA 658 Email: jpickens@com21.com 660 SIP Working Group Informational - Expires 8/31/02 12 661 SIP Extensions for Media Authorization February 2002 663 Poornima Lalwaney 664 Nokia 665 San Diego, CA 92121 666 Email: poornima.lalwaney@nokia.com 668 Jon Fellows 669 Copper Mountain Networks 670 San Diego, CA 92121 671 Email: jfellows@coppermountain.com 673 Doc Evans 674 D. R. Evans Consulting 675 Boulder, CO 80303 676 Email: n7dr@arrl.net 678 Keith Kelly 679 NetSpeak 680 Boca Raton, FL 33587 681 Email: keith@netspeak.com 683 SIP Working Group Informational - Expires 8/31/02 13 684 SIP Extensions for Media Authorization February 2002 686 Full Copyright Statement 688 "Copyright (C) The Internet Society (2002). All Rights Reserved. 689 This document and translations of it may be copied and furnished to 690 others, and derivative works that comment on or otherwise explain it 691 or assist in its implementation may be prepared, copied, published 692 and distributed, in whole or in part, without restriction of any 693 kind, provided that the above copyright notice and this paragraph 694 are included on all such copies and derivative works. However, this 695 document itself may not be modified in any way, such as by removing 696 the copyright notice or references to the Internet Society or other 697 Internet organizations, except as needed for the purpose of 698 developing Internet standards in which case the procedures for 699 copyrights defined in the Internet Standards process must be 700 followed, or as required to translate it into languages other than 701 English. The limited permissions granted above are perpetual and 702 will not be revoked by the Internet Society or its successors or 703 assigns. This document and the information contained herein is 704 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 705 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 706 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 707 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 708 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 710 SIP Working Group Informational - Expires 8/31/02 14