preemption ("preemption"). If queueing is used, the namespace MAY
indicate whether normal-priority requests are queued. If there is
a new "intended algorithm" other than preemption or priority
queueing, the algorithm must be described, taking into account all
RP actors (UAC, UAS, proxies).
o A namespace may either reference an existing list of priority
values or define a new finite list of priority values in relative
priority order for IANA registration within the sip-parameters
Resource-Priority priority-values registry. New priority-values
SHOULD NOT be added to a previously IANA-registered list
associated with a particular namespace, as this may cause
interoperability problems. Unless otherwise specified, it is
assumed that all priority values confer higher priority than
requests without a priority value.
o Any new SIP response codes unique to this new namespace need to be
explained and registered.
o The reference document must specify and describe any new Warning
header field warn-codes (RFC 3261, Section 27.2).
o The document needs to specify a new row for the following table
that summarizes the features of the namespace and is included into
IANA Resource-Priority Namespace registration:
Intended New New resp.
Namespace Levels algorithm warn-code code Reference
--------- ------ ---------------- --------- -------- ---------
<label> <# of <preemption <new warn <new resp. <RFC>
levels> or queue> code> code>
If information on new response codes, rejection codes, or error
behaviors is omitted, it is to be assumed that the namespace defines
no new parameters or behaviors.
10. Namespace Definitions
10.1. Introduction
This specification defines five unique namespaces below: DSN, DRSN,
Q735, ETS, and WPS, constituting their registration with IANA. Each
IANA registration contains the facets defined in Section 9. For
recognizability, we label the namespaces in capital letters, but note
that namespace names are case insensitive and are customarily
rendered as lowercase in protocol requests.
10.2. The "DSN" Namespace
The DSN namespace comes from the name of a US government network
called "The Defense Switched Network".
The DSN namespace has a finite list of relative priority-values,
listed below from lowest priority to highest priority:
(lowest) dsn.routine
dsn.priority
dsn.immediate
dsn.flash
(highest) dsn.flash-override
The DSN namespace uses the preemption algorithm (Section 4.5.1).
10.3. The "DRSN" Namespace
The DRSN namespace comes from the name of a US government network,
called "The Defense RED Switched Network".
The DRSN namespace defines the following resource values, listed from
lowest priority to highest priority:
(lowest) drsn.routine
drsn.priority
drsn.immediate
drsn.flash
drsn.flash-override
(highest) drsn.flash-override-override
The DRSN namespace uses the preemption algorithm (Section 4.5.1).
The DRSN namespace differs in one algorithmic aspect from the DSN and
Q735 namespaces. The behavior for the ’flash-override-override’
priority value differs from the other values. Normally, requests do
not preempt those of equal priority, but a newly arriving ’flash-
override-override’ request will displace another one of equal
priority if there are insufficient resources. This can also be
expressed as saying that ’flash-override-override’ requests defend
themselves as ’flash-override’ only.
10.4. The "Q735" Namespace
Q.735.3 [Q.735.3] was created to be a commercial version of the
operationally equivalent DSN specification for Multi-Level Precedence
and Preemption (MLPP). The Q735 namespace is defined here in the
same manner.
The Q735 namespace defines the following resource values, listed from
lowest priority to highest priority:
(lowest) q735.4
q735.3
q735.2
q735.1
(highest) q735.0
The Q735 namespace operates according to the preemption
(Section 4.5.1) algorithm.
10.5. The "ETS" Namespace
The ETS namespace derives its name indirectly from the name of the US
government telecommunications service, called "Government Emergency
Telecommunications Service" (or GETS), though the organization
responsible for the GETS service chose the acronym "ETS" for its GETS
over IP service, which stands for "Emergency Telecommunications
Service".
The ETS namespace defines the following resource values, listed from
lowest priority to highest priority:
(lowest) ets.4
ets.3
ets.2
ets.1
(highest) ets.0
The ETS namespace operates according to the priority queueing
algorithm (Section 4.5.2).
10.6. The "WPS" Namespace
The WPS namespace derives its name from the "Wireless Priority
Service", defined in GSM and other wireless technologies.
The WPS namespace defines the following resource values, listed from
lowest priority to highest priority:
(lowest) wps.4
wps.3
wps.2
wps.1
(highest) wps.0
The WPS namespace operates according to the priority queueing
algorithm (Section 4.5.2).
11. Security Considerations
11.1. General Remarks
Any resource priority mechanism can be abused to obtain resources and
thus deny service to other users. An adversary may be able to take
over a particular PSTN gateway, cause additional congestion during
emergencies affecting the PSTN, or deny service to legitimate users.
In SIP end systems, such as IP phones, this mechanism could
inappropriately terminate existing sessions and calls.
Thus, while the indication itself does not have to provide separate
authentication, SIP requests containing this header are very likely
to have higher authentication requirements than those without.
These authentication and authorization requirements extend to users
within the administrative domain, as later interconnection with other
administrative domains may invalidate earlier assumptions on the
trustworthiness of users.
Below, we describe authentication and authorization aspects,
confidentiality and privacy requirements, protection against denial-
of-service attacks, and anonymity requirements. Naturally, the
general discussion in RFC 3261 [RFC3261] applies.
All user agents and proxy servers that support this extension MUST
implement SIP over TLS [RFC3546], the ’sips’ URI scheme as described
in Section 26.2 of RFC 3261, and Digest Authentication [RFC2617] as
described in Section 22 of RFC 3261. In addition, user agents that
support this extension SHOULD also implement S/MIME [RFC3851] as
described in Section 23 of RFC 3261 to allow for signing and
verification of signatures over requests that use this extension.
11.2. Authentication and Authorization
Prioritized access to network and end-system resources imposes
particularly stringent requirements on authentication and
authorization mechanisms, since access to prioritized resources may
impact overall system stability and performance and not just result
in theft of, say, a single phone call.
Under certain emergency conditions, the network infrastructure,
including its authentication and authorization mechanism, may be
under attack.
Given the urgency during emergency events, normal statistical fraud
detection may be less effective, thus placing a premium on reliable
authentication.
Common requirements for authentication mechanisms apply, such as
resistance to replay, cut-and-paste, and bid-down attacks.
Authentication MAY be SIP based or use other mechanisms. Use of
Digest authentication and/or S/MIME is RECOMMENDED for UAS
authentication. Digest authentication requires that the parties
share a common secret, thus limiting its use across administrative
domains. SIP systems employing resource priority SHOULD implement
S/MIME at least for integrity, as described in Section 23 of
[RFC3261]. However, in some environments, receipt of asserted
identity [RFC3325] from a trusted entity may be sufficient
authorization. Section 5 describes third-party authentication.
Trait-based authorization [TRAIT] "entails an assertion by a
authorization service of attributes associated with an identity" and
may be appropriate for this application. With trait-based
authorization, a network element can directly determine, by
inspecting the certificate, that a request is authorized to obtain a
particular type of service, without having to consult a mapping
mechanism that converts user identities to authorizations.
Authorization may be based on factors besides the identity of the
caller, such as the requested destination. Namespaces MAY also
impose particular authentication or authorization considerations that
are stricter than the baseline described here.
11.3. Confidentiality and Integrity
Calls that use elevated resource priority levels provided by the
’Resource-Priority’ header field are likely to be sensitive and often
need to be protected from intercept and alteration. In particular,
requirements for protecting the confidentiality of communications
relationships may be higher than those for normal commercial service.
For SIP, the ’To’, ’From’, ’Organization’, and ’Subject’ header
fields are examples of particularly sensitive information. Systems
MUST implement encryption at the transport level using TLS and MAY
implement other transport-layer or network-layer security mechanisms.
UACs SHOULD use the "sips" URI to request a secure transport
association to the destination.
The ’Resource-Priority’ header field can be carried in the SIP
message header or can be encapsulated in a message fragment carried
in the SIP message body [RFC3420]. To be considered valid
authentication for the purposes of this specification, S/MIME-signed
SIP messages or fragments MUST contain, at a minimum, the Date, To,
From, Call-ID, and Resource-Priority header fields. Encapsulation in
S/MIME body parts allows the user to protect this header field
against inspection or modification by proxies. However, in many
cases, proxies will need to authenticate and authorize the request,
so encapsulation would be undesirable.
Removal of a Resource-Priority header field or downgrading its
priority value affords no additional opportunities to an adversary,
since that man-in-the-middle could simply drop or otherwise
invalidate the SIP request and thus prevent call completion.
Only SIP elements within the same administrative trust domain
employing a secure channel between their SIP elements will trust a
Resource-Priority header field that is not appropriately signed.
Others will need to authenticate the request independently. Thus,
insertion of a Resource-Priority header field or upgrading the
priority value has no further security implications except causing a
request to fail (see discussion in the previous paragraph).
11.4. Anonymity
Some users may wish to remain anonymous to the request destination.
Anonymity for requests with resource priority is no different from
that for any other authenticated SIP request. For the reasons noted
earlier, users have to authenticate themselves towards the SIP
elements carrying the request where they desire resource priority
treatment. The authentication may be based on capabilities and noms,
not necessarily their civil name. Clearly, they may remain anonymous
towards the request destination, using the network-asserted identity
and general privacy mechanism described in [RFC3323].
11.5. Denial-of-Service Attacks
As noted, systems described here are likely to be subject to
deliberate denial-of-service (DoS) attacks during certain types of
emergencies. DoS attacks may be launched on the network itself as
well as on its authentication and authorization mechanism. As noted,
systems should minimize the amount of state, computation, and network
resources that an unauthorized user can command. The system must not
amplify attacks by causing the transmission of more than one packet
to a network address whose reachability has not been verified.
12. IANA Considerations
12.1. Introduction
This section defines two new SIP headers (Section 12.2), one SIP
option tag (Section 12.3), one new 4xx error code (Section 12.4), a
new registry within the sip-parameters section of IANA for Resource-
Priority namespaces (Section 12.5), and a new registry within the
sip-parameters section of IANA for Resource-Priority and priority-
values (Section 12.6).
Additional namespaces and priority values MUST be registered with
IANA, as described in Section 9.
The SIP Change Process [RFC3427] establishes a policy for the
registration of new SIP extension headers. Resource priority
namespaces and priority values have similar interoperability
requirements to those of SIP extension headers. Consequently,
registration of new resource priority namespaces and priority values
requires documentation in an RFC using the extension header approval
process specified in RFC 3427.
Registration policies for new namespaces are defined in Section 9.
12.2. IANA Registration of ’Resource-Priority’ and ’Accept-Resource-
Priority’ Header Fields
The following is the registration for the ’Resource-Priority’ header
field:
RFC number: 4412
Header name: ’Resource-Priority’
Compact form: none
The following is the registration for the ’Accept-Resource-Priority’
header field:
RFC number: 4412
Header name: Accept-Resource-Priority
Compact form: none
12.3. IANA Registration for Option Tag resource-priority
RFC number: 4412
Name of option tag: ’resource-priority’
Descriptive text: Indicates or requests support for the resource
priority mechanism.
12.4. IANA Registration for Response Code 417
RFC number: 4412
Response code: 417
Default reason phrase: Unknown Resource-Priority
12.5. IANA Resource-Priority Namespace Registration
A new registry ("Resource-Priority Namespaces") in the sip-parameters
section of IANA has been created, taking a form similar to this table
below:
Intended New warn- New resp.
Namespace Levels Algorithm code code Reference
--------- ------ ---------------- --------- --------- ---------
dsn 5 preemption no no [RFC4412]
drsn 6 preemption no no [RFC4412]
q735 5 preemption no no [RFC4412]
ets 5 queue no no [RFC4412]
wps 5 queue no no [RFC4412]
Legend
------
Namespace The unique string identifying the namespace.
Levels The number of priority-values within the namespace.
Algorithm Intended operational behavior of SIP elements
implementing this namespace.
New Warn code New Warning Codes (warn-codes) introduced by
this namespace.
New Resp. code New SIP response codes introduced by this namespace.
Reference IETF document reference for this namespace.
12.6. IANA Priority-Value Registrations
A new registry ("Resource-Priority Priority-values") in the sip-
parameters section of IANA has been created, taking a form similar to
this table below:
Namespace: drsn
Reference: RFC 4412
Priority-Values (least to greatest): "routine", "priority",
"immediate", "flash", "flash-override", "flash-override-override"
Namespace: dsn
Reference: RFC 4412
Priority-Values (least to greatest): "routine", "priority",
"immediate", "flash", "flash-override"
Namespace: q735
Reference: RFC 4412
Priority values (least to greatest): "4", "3", "2", "1", "0"
Namespace: ets
Reference: RFC 4412
Priority values (least to greatest): "4", "3", "2", "1", "0"
Namespace: wps
Reference: RFC 4412
Priority values (least to greatest): "4", "3", "2", "1", "0"
13. Acknowledgements
Ben Campbell, Ken Carlberg, Paul Kyzivat, Rohan Mahy, Allison Mankin,
Xavier Marjou, Piers O’Hanlon, Mike Pierce, Samir Srivastava, and
Dale Worley provided helpful comments.
Dean Willis provided much help with this effort.
Martin Dolly, An Nguyen, and Niranjan Sandesara assisted with the ETS
and WPS namespaces.
Janet Gunn helped improve the text on queueing-based priority.
14. References
14.1. Normative References
[I.255.3] International Telecommunications Union, "Integrated
Services Digital Network (ISDN) - General Structure and
Service Capabilities - Multi-Level Precedence and
Preemption", Recommendation I.255.3, July 1990.
[Q.735.3] International Telecommunications Union, "Stage 3
description for community of interest supplementary
services using Signalling System No. 7: Multi-level
precedence and preemption", Recommendation Q.735.3,
March 1993.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3261] 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.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, June 2002.
[RFC3265] Roach, A.B., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002.
[RFC3420] Sparks, R., "Internet Media Type message/sipfrag", RFC
3420, November 2002.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002.
[RFC4411] Polk, J., "Extending the Session Initiation Protocol (SIP)
Reason Header for Preemption Events", RFC 4411, February
2006.
14.2. Informative References
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October
2000.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J.,
and B. Rosen, "Change Process for the Session Initiation
Protocol (SIP)", BCP 67, RFC 3427, December 2002.
[RFC3487] Schulzrinne, H., "Requirements for Resource Priority
Mechanisms for the Session Initiation Protocol (SIP)", RFC
3487, February 2003.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 3546, June 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and
K. Summers, "Session Initiation Protocol (SIP) Basic Call
Flow Examples", BCP 75, RFC 3665, December 2003.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[RFC3893] Peterson, J., "Session Initiation Protocol (SIP)
Authenticated Identity Body (AIB) Format", RFC 3893,
September 2004.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004. for
Event State Publication", RFC 3903, October 2004.
[TRAIT] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig,
"Trait-based Authorization Requirements for the Session
Initiation Protocol (SIP)", Work in Progress,
February 2005.
Authors’ Addresses
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7004
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
James Polk
Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX 75082
US
EMail: jmpolk@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an