File: rfc3313.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (899 lines) | stat: -rw-r--r-- 36,866 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899






Network Working Group                                   W. Marshall, Ed.
Request for Comments: 3313                                          AT&T
Category: Informational                                     January 2003


          Private Session Initiation Protocol (SIP) Extensions
                        for Media Authorization

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This document describes the need for Quality of Service (QoS) and
   media authorization and defines a Session Initiation Protocol (SIP)
   extension that can be used to integrate QoS admission control with
   call signaling and help guard against denial of service attacks.  The
   use of this extension is only applicable in administrative domains,
   or among federations of administrative domains with previously
   agreed-upon policies, where both the SIP proxy authorizing the QoS,
   and the policy control of the underlying network providing the QoS,
   belong to that administrative domain or federation of domains.






















Marshall, Ed.                Informational                      [Page 1]

RFC 3313         SIP Extensions for Media Authorization     January 2003


Table of Contents

   1. Scope of Applicability.........................................  2
   2. Conventions Used in this Document..............................  3
   3. Background and Motivation......................................  3
   4. Overview.......................................................  4
   5. Changes to SIP to Support Media Authorization..................  4
      5.1 SIP Header Extension.......................................  5
      5.2 SIP Procedures.............................................  5
        5.2.1 User Agent Client (UAC)................................  6
        5.2.2 User Agent Server (UAS)................................  6
        5.2.3 Originating Proxy (OP).................................  7
        5.2.4 Destination Proxy (DP).................................  7
   6. Examples.......................................................  8
      6.1 Requesting Bandwidth via RSVP Messaging....................  8
        6.1.1 User Agent Client Side.................................  8
        6.1.2 User Agent Server Side................................. 10
   7. Advantages of the Proposed Approach............................ 12
   8. Security Considerations........................................ 13
   9. IANA Considerations............................................ 13
   10. Notice Regarding Intellectual Property Rights................. 13
   11. Normative References.......................................... 14
   12. Informative References........................................ 14
   13. Contributors.................................................. 15
   14. Acknowledgments............................................... 15
   15. Editor's Address.............................................. 15
   16. Full Copyright Statement...................................... 16

1. Scope of Applicability

   This document defines a SIP extension that can be used to integrate
   QoS admission control with call signaling and help guard against
   denial of service attacks.  The use of this extension is only
   applicable in administrative domains, or among federations of
   administrative domains with previously agreed-upon policies, where
   both the SIP proxy authorizing the QoS, and the policy control of the
   underlying network providing the QoS, belong to that administrative
   domain or federation of domains.  Furthermore, the mechanism is
   generally incompatible with end-to-end encryption of message bodies
   that describe media sessions.

   This is in contrast with general Internet principles, which separate
   data transport from applications.  Thus, the solution described in
   this document is not applicable to the Internet at large.  Despite
   these limitations, there are sufficiently useful specialized
   deployments that meet the assumptions described above, and can accept
   the limitations that result, to warrant informational publication of
   this mechanism.  An example deployment would be a closed network,



Marshall, Ed.                Informational                      [Page 2]

RFC 3313         SIP Extensions for Media Authorization     January 2003


   which emulates a traditional circuit switched telephone network.
   This document specifies a private header, facilitating use in these
   specialized configurations.

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

   Current IP telephony systems assume a perfect world in which there is
   either an unlimited amount of bandwidth, or network layer Quality of
   Service (QoS) is provided without any kind of policy control.
   However, the reality is that end-to-end bandwidth is not unlimited
   and uncontrolled access to QoS, in general, is unlikely.  The primary
   reason for this is that QoS provides preferential treatment of one
   flow, at the expense of another.  Consequently, it is important to
   have policy control over whether a given flow should have access to
   QoS.  This will not only enable fairness in general, but can also
   prevent denial of service attacks.

   In this document, we are concerned with providing QoS for media
   streams established via the Session Initiation Protocol (SIP) [3].
   We assume an architecture that integrates call signaling with media
   authorization, as illustrated in the Figure below.  The solid lines
   (A and B) show interfaces, whereas the dotted line (C) illustrates
   the QoS enabled media flow:

                               +---------+
                               |  Proxy  |
                    +--------->|         |
                    |          +---------+
                    |               ^
                  A)|            B) |
                    |              { }
                    |               |
                    |               v
                    v           +------+
                +------+   C)   | Edge |
                |  UA  |........|router|......
                +------+        +------+


                       Figure 1 - Basic Architecture





Marshall, Ed.                Informational                      [Page 3]

RFC 3313         SIP Extensions for Media Authorization     January 2003


   In this architecture, we assume a SIP UA connected to a QoS enabled
   network with an edge router acting as a Policy Enforcement Point
   (PEP) [6].  We further assume that a SIP UA that wishes to obtain QoS
   initiates sessions through a proxy which can interface with the QoS
   policy control for the data network being used.  We will refer to
   such a proxy as a QoS enabled proxy.  We assume that the SIP UA needs
   to present an authorization token to the network in order to obtain
   Quality of Service (C).  The SIP UA obtains this authorization token
   via SIP (A) from the QoS enabled proxy by means of an extension SIP
   header, defined in this document.  The proxy, in turn, communicates
   either directly with the edge router or with a Policy Decision Point
   (PDP - not shown) [6] in order to obtain a suitable authorization
   token for the UA.

   Examples of access data networks, where such a QoS enabled proxy
   could be used, include DOCSIS based cable networks and 3rd generation
   (3G) wireless networks.

4. Overview

   A session that needs to obtain QoS for the media streams in
   accordance with our basic architecture described above goes through
   the following steps.

   The SIP UA sends an INVITE to the QoS enabled proxy, which for each
   resulting dialog includes one or more media authorization tokens in
   all unreliable provisional responses (except 100), the first reliable
   1xx or 2xx response, and all retransmissions of that reliable
   response for the dialog.  When the UA requests QoS, it includes the
   media authorization tokens with the resource reservation.

   A SIP UA may also receive an INVITE from its QoS enabled proxy which
   includes one or more media authorization tokens.  In that case, when
   the UA requests QoS, it includes the media authorization tokens with
   the resource reservation.  The resource reservation mechanism is not
   part of SIP and is not described within the scope of this document.

5. Changes to SIP to Support Media Authorization

   This document defines a private SIP header extension to support a
   media authorization scheme.  In this architecture, a QoS enabled SIP
   proxy supplies the UA with one or more authorization tokens which are
   to be used in QoS requests.  The extension defined allows network QoS
   resources to be authorized by the QoS enabled SIP proxy.







Marshall, Ed.                Informational                      [Page 4]

RFC 3313         SIP Extensions for Media Authorization     January 2003


5.1 SIP Header Extension

   A new P-Media-Authorization general header field is defined.  The P-
   Media-Authorization header field contains one or more media
   authorization tokens which are to be included in subsequent resource
   reservations for the media flows associated with the session, that
   is, passed to an independent resource reservation mechanism, which is
   not specified here.  The media authorization tokens are used for
   authorizing QoS for the media stream(s).  The P-Media-Authorization
   header field is described by the following ABNF [4]:

      P-Media-Authorization   = "P-Media-Authorization" HCOLON
                                  P-Media-Authorization-Token
                                  *(COMMA P-Media-Authorization-Token)

      P-Media-Authorization-Token = 1*HEXDIG

   Table 1 below is an extension of tables 2 and 3 in [3] for the new
   header field defined here.  For informational purposes, this table
   also includes relevant entries for standards track extension methods
   published at the time this document was published.  The INFO, PRACK,
   UPDATE, and SUBSCRIBE and NOTIFY methods are defined respectively in
   [11], [9], [12], and [10].

                              Where  proxy  ACK  BYE  CAN  INV  OPT  REG
      P-Media-Authorization     R      ad    o    -    -    o    -    -
      P-Media-Authorization    2xx     ad    -    -    -    o    -    -
      P-Media-Authorization  101-199   ad    -    -    -    o    -    -

                              Where  proxy  INF  PRA  UPD  SUB  NOT
      P-Media-Authorization     R      ad    -    o    o    -    -
      P-Media-Authorization    2xx     ad    -    o    o    -    -

                      Table 1: Summary of header fields.

   The P-Media-Authorization header field can be used only in SIP
   requests or responses that can carry a SIP offer or answer.  This
   naturally keeps the scope of this header field narrow.

5.2 SIP Procedures

   This section defines SIP [3] procedures for usage in media
   authorization compatible systems, from the point of view of the
   authorizing QoS.







Marshall, Ed.                Informational                      [Page 5]

RFC 3313         SIP Extensions for Media Authorization     January 2003


5.2.1 User Agent Client (UAC)

   The initial SIP INVITE message, mid-call messages that result in
   network QoS resource changes, and mid-call changes in call
   destination should be authorized.  These SIP messages are sent
   through the QoS enabled proxies to receive this authorization.  In
   order to authorize QoS, the QoS enabled SIP proxy MAY need to inspect
   message bodies that describe the media streams (e.g., SDP).  Hence,
   it is recommended (as may be appropriate within the applicability
   scope in Section 1 of this document) that such message bodies not be
   encrypted end-to-end.

   The P-Media-Authorization-Token, which is contained in the P-Media-
   Authorization header, is included for each dialog in all unreliable
   provisional responses (except 100), the first reliable 1xx or 2xx
   response, and all retransmissions of that reliable response for the
   dialog sent by the QoS enabled SIP proxy to the UAC.

   The UAC should use all the P-Media-Authorization-Tokens from the most
   recent request/response that contained the P-Media-Authorization
   header when requesting QoS for the associated media stream(s).  This
   applies to both initial and subsequent refresh reservation messages
   (for example, in an RSVP-based reservation system).  A reservation
   function within the UAC should convert each string of hex digits into
   binary, and utilize each result as a Policy-Element, as defined in
   RFC 2750 [5] (excluding Length, but including P-Type which is
   included in each token).  These Policy-Elements would typically
   contain the authorizing entity and credentials, and be used in an
   RSVP request for media data stream QoS resources.

5.2.2 User Agent Server (UAS)

   The User Agent Server receives the P-Media-Authorization-Token in an
   INVITE (or other) message from the QoS enabled SIP proxy.  If the
   response contains a message body that describes media streams for
   which the UA desires QoS, it is recommended (as may be appropriate
   within the applicability scope in Section 1 of this document) that
   this message body not be encrypted end-to-end.

   The UAS should use all the P-Media-Authorization-Tokens from the most
   recent request/response that contained the P-Media-Authorization
   header when requesting QoS for the associated media stream(s).  This
   applies both to initial and subsequent refresh reservation messages
   (for example, in an RSVP-based reservation system).  A reservation
   function within the UAS should convert each string of hex digits into
   binary, and utilize each result as a Policy-Element, as defined in
   RFC 2750 [5] (excluding Length, but including P-Type which is
   included in each token).  These Policy-Elements would typically



Marshall, Ed.                Informational                      [Page 6]

RFC 3313         SIP Extensions for Media Authorization     January 2003


   contain the authorizing entity and credentials, and be used in an
   RSVP request for media data stream QoS resources.

5.2.3 Originating Proxy (OP)

   When the originating QoS enabled proxy (OP) receives an INVITE (or
   other) message from the UAC, the proxy authenticates the caller, and
   verifies that the caller is authorized to receive QoS.

   In cooperation with an originating Policy Decision Point (PDP-o), the
   OP obtains and/or generates one or more media authorization tokens.
   These contain sufficient information for the UAC to get the
   authorized QoS for the media streams.  Each media authorization token
   is formatted as a Policy-Element, as defined in RFC 2750 [5]
   (excluding Length, but including P-Type which is included in each
   token), and then converted to a string of hex digits to form a P-
   Media-Authorization-Token.  The proxy's resource management function
   may inspect message bodies that describe the media streams (e.g.,
   SDP), in both requests and responses in order to decide what QoS to
   authorize.

   For each dialog that results from the INVITE (or other) message
   received from the UAC, the originating proxy must add a P-Media-
   Authorization header with the P-Media-Authorization-Token in all
   unreliable provisional responses (except 100), the first reliable 1xx
   or 2xx response, and all retransmissions of that reliable response
   the proxy sends to the UAC, if that response may result in network
   QoS changes.  A response with an SDP may result in such changes.

5.2.4 Destination Proxy (DP)

   The Destination QoS Enabled Proxy (DP) verifies that the called party
   is authorized to receive QoS.

   In cooperation with a terminating Policy Decision Point (PDP-t), the
   DP obtains and/or generates a media authorization token that contains
   sufficient information for the UAS to get the authorized QoS for the
   media streams.  The media authorization token is formatted as a
   Policy-Element, as defined in RFC 2750 [5] (excluding Length, but
   including P-Type which is included in each token), and then converted
   to a string of hex digits to form a P-Media-Authorization-Token.  The
   proxy's resource management function may inspect message bodies that
   describe the media streams (e.g., SDP), in both requests and
   responses in order to decide what QoS to authorize.







Marshall, Ed.                Informational                      [Page 7]

RFC 3313         SIP Extensions for Media Authorization     January 2003


   The Destination Proxy must add the P-Media-Authorization header with
   the P-Media-Authorization-Token in the INVITE (or other) request that
   it sends to the UAS if that message may result in network QoS
   changes.  A message with an SDP body may result in such changes.

6. Examples

6.1 Requesting Bandwidth via RSVP Messaging

   Below we provide an example of how the P-Media-Authorization header
   field can be used in conjunction with the Resource Reservation
   Protocol (RSVP) [7].  The example assumes that an offer arrives in
   the initial INVITE and an answer arrives in a reliable provisional
   response [9], which contains an SDP description of the media flow.

6.1.1 User Agent Client Side

   Figure 2 presents a high-level overview of a basic call flow with
   media authorization from the viewpoint of the UAC.  Some policy
   interactions have been omitted for brevity.

   When a user goes off-hook and dials a telephone number, the UAC
   collects the dialed digits and sends the initial (1)INVITE message to
   the originating SIP proxy.

   The originating SIP proxy (OP) authenticates the user/UAC and
   forwards the (2)INVITE message to the proper SIP proxy.

   Assuming the call is not forwarded, the terminating end-point sends a
   (3)18x response to the initial INVITE via OP.  Included in this
   response is an indication of the negotiated bandwidth requirement for
   the connection (in the form of an SDP description [8]).

   When OP receives the (3)18x, it has sufficient information regarding
   the end-points, bandwidth and characteristics of the media exchange.
   It initiates a Policy-Setup message to PDP-o, (4)AuthProfile.

   The PDP-o stores the authorized media description in its local store,
   generates an authorization token that points to this description, and
   returns the authorization token to the OP, (5)AuthToken.











Marshall, Ed.                Informational                      [Page 8]

RFC 3313         SIP Extensions for Media Authorization     January 2003


   UAC         ER-o            PDP-o           OP
   |(1)INVITE   |               |               | Client Authentication
   |------------------------------------------->| and Call Authoriz.
   |            |               |               | (2)INVITE
   |            |               |               |-------------->
   |            |               |               | (3)18x
   |            |               |(4)AuthProfile |<--------------
   |            |               |<--------------|
   |            |               |(5)AuthToken   |
   |            |               |-------------->| Auth. Token put into
   |            |               |        (6)18x | P-Media-Authorization
   |<-------------------------------------------| header extension.
   |---(7)PRACK-------------------------------->|
   |                                            |--(8)PRACK---->
   |                                            |<-(9)200 (PRACK)
   |<--(10)200 (PRACK)--------------------------|
   |            |               |               |
   |Copies the RSVP policy object               |
   |from the P-Media-Authorization              |
   |(11)RSVP-PATH               |               |
   |----------->| (12)REQ       |               |
   |            |-------------->| Using the Auth-Token and Authorized
   |            |       (13)DEC | Profile that is set by the SIP Proxy
   |            |<--------------| the PDP makes the decision
   |            |               |               |(14)RSVP-PATH
   |            |------------------------------------------------>
   |            |               |               |(15)RSVP-PATH
   |<--------------------------------------------------------------
   |Copies the RSVP policy object               |
   |from the P-Media-Authorization              |
   |(16)RSVP-RESV               |               |
   |----------->|   (17)REQ     |               |
   |            |-------------->| Using the Auth-Token and Authorized
   |            |   (18)DEC     | Profile that is set by the SIP Proxy
   |            |<--------------| the PDP makes the decision
   |            |               |               |(19)RSVP-RESV
   |            |--------------------------------------------------->
   |            |               |               |(20)RSVP-RESV
   |<----------------------------------------------------------------
   |            |               |               |

             Figure 2 - Media Authorization with RSVP (UAC)

   The OP includes the authorization token in the P-Media-Authorization
   header extension of the (6)18x message.






Marshall, Ed.                Informational                      [Page 9]

RFC 3313         SIP Extensions for Media Authorization     January 2003


   Upon receipt of the (6)18x message, the UAC stores the media
   authorization token from the P-Media-Authorization header.  Also, the
   UAC acknowledges the 18x message by sending a (7)PRACK message, which
   is responded to with (10) 200.

   Before sending any media, the UAC requests QoS by sending an
   (11)RSVP-PATH message, which includes the previously stored P-Media-
   Authorization-Token as a Policy-Element.

   ER-o, upon receipt of the (11)RSVP-PATH message, checks the
   authorization through a PDP-o COPS message exchange, (12)REQ.  PDP-o
   checks the authorization using the stored authorized media
   description that was linked to the authorization token it returned to
   OP.  If authorization is successful, PDP-o returns an "install"
   Decision, (13)DEC.

   ER-o checks the admissibility for the request, and if admission
   succeeds, it forwards the (14)RSVP-PATH message.

   Once UAC receives the (15)RSVP-PATH message from UAS, it sends the
   (16)RSVP-RESV message to reserve the network resources.

   ER-o, upon receiving the (16)RSVP-RESV message checks the
   authorization through a PDP-o COPS message exchange, (17)REQ.  PDP-o
   checks the authorization using the stored authorized media
   description that was linked to the authorization token it returned to
   OP.  If authorization is successful, PDP-o returns an "install"
   Decision, (18)DEC.

   ER-o checks the admissibility for the request, and if admission
   succeeds, it forwards the (19)RSVP-RESV message.

   Upon receiving the (20)RSVP-RESV message, network resources have been
   reserved in both directions.

6.1.2 User Agent Server Side

   Figure 3 presents a high-level overview of a call flow with media
   authorization from the viewpoint of the UAS.  Some policy
   interactions have been omitted for brevity.

   Since the destination SIP proxy (DP) has sufficient information
   regarding the endpoints, bandwidth, and characteristics of the media
   exchange, it initiates a Policy-Setup message to the terminating
   Policy Decision Point (PDP-t) on receipt of the (1)INVITE.






Marshall, Ed.                Informational                     [Page 10]

RFC 3313         SIP Extensions for Media Authorization     January 2003


   UAS         ER-t           PDP-t            DP
    |           |               |               | (1)INVITE
    |           |               |               |<--------------
    |           |               |               | Proxy Authentication
    |           |               | (2)AuthProfile| and Call Authoriz.
    |           |               |<--------------|
    |           |               | (3)AuthToken  |
    |           |               |-------------->| Auth. Token put into
    |           |               |     (4)INVITE | P-Media-Authorization
    |<------------------------------------------| header extension
    |  (5)18x   |               |               |
    |------------------------------------------>| (6)18x
    |Copies the RSVP policy object              |-------------->
    |from the P-Media-Authorization             |
    |(7)RSVP-PATH               |               |
    |---------->| (8)REQ        |               |
    |           |-------------->| Using the Auth-Token and Authorized
    |           |       (9)DEC  | Profile that is set by the SIP Proxy
    |           |<--------------| the PDP makes the decision
    |           |               |               |(10)RSVP-PATH
    |           |-------------------------------------------------->
    |           |               |               |(11)RSVP-PATH
    |<--------------------------------------------------------------
    |Copies the RSVP policy object              |
    |from the P-Media-Authorization             |
    | (12)RSVP-RESV             |               |
    |---------->|               |               |
    |           | (13)REQ       |               |
    |           |-------------->| Using the Auth-Token and Authorized
    |           |       (14)DEC | Profile that is set by the SIP Proxy
    |           |<--------------| the PDP makes the decision
    |           |               |               |(15)RSVP-RESV
    |           |--------------------------------------------------->
    |           |               |               |(16)RSVP-RESV
    |<---------------------------------------------------------------
    |           |               |               |<-(17)PRACK---------
    |<--(18)PRACK ------------------------------|
    |---(19)200 (PRACK) ----------------------->|
    |           |               |               |--(20)200 (PRACK)-->
    |           |               |               |

              Figure 3 - Media Authorization with RSVP (UAS)

   PDP-t stores the authorized media description in its local store,
   generates an authorization token that points to this description, and
   returns the authorization token to DP.  The token is placed in the
   (4)INVITE message and forwarded to the UAS.




Marshall, Ed.                Informational                     [Page 11]

RFC 3313         SIP Extensions for Media Authorization     January 2003


   Assuming that the call is not forwarded, the UAS sends a (5)18x
   response to the initial INVITE message, which is forwarded back to
   UAC.  At the same time, the UAS sends a (7)RSVP-PATH message which
   includes the previously stored P-Media-Authorization-Token as a
   Policy-Element.

   ER-t, upon receiving the (7)RSVP-PATH message checks the
   authorization through a PDP-t COPS message exchange.  PDP-t checks
   the authorization using the stored authorized media description that
   was linked to the authorization token it returned to DP.  If
   authorization is successful, PDP-t returns an "install" Decision,
   (9)DEC.

   ER-t checks the admissibility for the request, and if admission
   succeeds, it forwards the (10)RSVP-PATH message.

   Once the UAS receives the (11)RSVP-PATH message, it sends the
   (12)RSVP-RESV message to reserve the network resources.

   ER-t, upon reception of the (12)RSVP-RESV message, checks the
   authorization through a PDP-t COPS message exchange.  PDP-t checks
   the authorization using the stored authorized media description that
   was linked to the authorization token that it returned to DP.  If
   authorization is successful, PDP-t returns an "install" Decision,
   (14)DEC.

   ER-t checks the admissibility for the request and if admission
   succeeds, it forwards the (15)RSVP-RESV message.

   Upon receiving the (16)RSVP-RESV message, network resources have been
   reserved in both directions.

   For completeness, we show the (17)PRACK message for the (5) 18x
   response and the resulting (19) 200 response acknowledging the PRACK.

7. Advantages of the Proposed Approach

   The use of media authorization makes it possible to control the usage
   of network resources.  In turn, this makes IP Telephony more robust
   against denial of service attacks and various kinds of service
   frauds.  By using the authorization capability, the number of flows,
   and the amount of network resources reserved can be controlled,
   thereby making the IP Telephony system dependable in the presence of
   scarce resources.







Marshall, Ed.                Informational                     [Page 12]

RFC 3313         SIP Extensions for Media Authorization     January 2003


8. Security Considerations

   In order to control access to QoS, a QoS enabled proxy should
   authenticate the UA before providing it with a media authorization
   token.  Both the method and policy associated with such
   authentication are outside the scope of this document, however it
   could, for example, be done by using standard SIP authentication
   mechanisms, as described in [3].

   Media authorization tokens sent in the P-Media-Authorization header
   from a QoS enabled proxy to a UA MUST be protected from eavesdropping
   and tampering.  This can, for example, be done through a mechanism
   such as IPSec or TLS.  However, this will only provide hop-by-hop
   security.  If there is one or more intermediaries (e.g., proxies),
   between the UA and the QoS enabled proxy, these intermediaries will
   have access to the P-Media-Authorization header field value, thereby
   compromising confidentiality and integrity.  This will enable both
   theft-of-service and denial-of-service attacks against the UA.
   Consequently, the P-Media-Authorization header field MUST NOT be
   available to any untrusted intermediary in the clear or without
   integrity protection.  There is currently no mechanism defined in SIP
   that would satisfy these requirements.  Until such a mechanism
   exists, proxies MUST NOT send P-Media-Authorization headers through
   untrusted intermediaries, which might reveal or modify the contents
   of this header.  (Note that S/MIME-based encryption in SIP is not
   available to proxy servers, as proxies are not allowed to add message
   bodies.)

   QoS enabled proxies may need to inspect message bodies describing
   media streams (e.g., SDP).  Consequently, such message bodies should
   not be encrypted.  In turn, this will prevent end-to-end
   confidentiality of the said message bodies, which lowers the overall
   security possible.

9. IANA Considerations

   This document defines a new private SIP header for media
   authorization, "P-Media-Authorization".  This header has been
   registered by the IANA in the SIP header registry, using the RFC
   number of this document as its reference.

10. Notice Regarding Intellectual Property Rights

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.




Marshall, Ed.                Informational                     [Page 13]

RFC 3313         SIP Extensions for Media Authorization     January 2003


11. Normative References

   [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]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

   [4]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

   [5]  Herzog, S., "RSVP Extensions for Policy Control", RFC 2750,
        January 2000.

12. Informative References

   [6]  Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for
        Policy-based Admission Control", RFC 2753, January 2000.

   [7]  Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
        "Resource Reservation Protocol (RSVP) -- Version 1 Functional
        Specification", RFC 2205, September 1997.

   [8]  Handley, M. and V. Jacobson, "SDP: Session Description
        Protocol", RFC 2327, April 1998.

   [9]  Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
        Responses in Session Initiation Protocol (SIP)", RFC 3262, June
        2002.

   [10] Roach, A. B., "Session Initiation Protocol (SIP)-Specific Event
        Notification", RFC 3265, June 2002.

   [11] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.

   [12] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
        Method", RFC 3311, September 2002.










Marshall, Ed.                Informational                     [Page 14]

RFC 3313         SIP Extensions for Media Authorization     January 2003


13. Contributors

   The following people contributed significantly and were co-authors on
   earlier versions of this document:

      Bill Marshall (AT&T), K. K. Ramakrishnan (AT&T), Ed Miller
      (Terayon), Glenn Russell (CableLabs), Burcak Beser (Juniper
      Networks), Mike Mannette (3Com), Kurt Steinbrenner (3Com), Dave
      Oran (Cisco), Flemming Andreasen (Cisco), John Pickens (Com21),
      Poornima Lalwaney (Nokia), Jon Fellows (Copper Mountain Networks),
      Doc Evans (Arris), and Keith Kelly (NetSpeak).

14. Acknowledgments

   The Distributed Call Signaling work in the PacketCable project is the
   work of a large number of people, representing many different
   companies.  The contributors would like to recognize and thank the
   following for their assistance: John Wheeler, Motorola; David
   Boardman, Daniel Paul, Arris Interactive; Bill Blum, 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.  Dean Willis and Rohan Mahy provided valuable
   feedback as well.

15. Editor's Address

   Bill Marshall
   AT&T
   Florham Park, NJ  07932

   EMail: wtm@research.att.com

















Marshall, Ed.                Informational                     [Page 15]

RFC 3313         SIP Extensions for Media Authorization     January 2003


16. Full Copyright Statement

   Copyright (C) The Internet Society (2003).  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 implementation 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Marshall, Ed.                Informational                     [Page 16]