Network Working Group H. Schulzrinne Internet-Draft Columbia U. Expires: February 27, 2005 J. Polk Cisco August 29, 2004 Communications Resource Priority for the Session Initiation Protocol (SIP) draft-ietf-sip-resource-priority-04 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 27, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document defines two new SIP header fields for communications resource priority, namely "Resource-Priority" and "Accept-Resource-Priority". The "Resource-Priority" header field can influence the behavior of SIP user agents, such as telephone gateways and IP telephones, and Session Initiation Protocol (SIP) proxies. It does not directly influence the forwarding behavior of IP routers. Schulzrinne & Polk Expires February 27, 2005 [Page 1] Internet-Draft SIP Resource Priority August 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. The Resource-Priority and Accept-Resource-Priority SIP Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 The 'Resource-Priority' Header Field . . . . . . . . . . . 6 3.2 The 'Accept-Resource-Priority' Header Field . . . . . . . 7 3.3 Usage of the 'Resource-Priority' and 'Accept-Resource-Priority' Header Fields . . . . . . . . . 7 3.4 The 'resource-priority' Option Tag . . . . . . . . . . . . 8 4. Behavior of SIP Elements that Receive Prioritized Requests . . 8 4.1 General Rules . . . . . . . . . . . . . . . . . . . . . . 8 4.2 Error Conditions . . . . . . . . . . . . . . . . . . . . . 9 4.2.1 Known Namespace and Priority Value . . . . . . . . . . 9 4.2.2 Handling Unknown Namespaces and Priority Values . . . 9 4.3 User Agent Client Behavior . . . . . . . . . . . . . . . . 10 4.4 User Agent Server Behavior . . . . . . . . . . . . . . . . 11 4.5 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 11 5. Third-Party Authentication . . . . . . . . . . . . . . . . . . 12 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 12 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1 Simple Call . . . . . . . . . . . . . . . . . . . . . . . 13 7.2 Receiver Does Not Understand Namespace . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8.1 Authentication and Authorization . . . . . . . . . . . . . 17 8.2 Confidentiality and Integrity . . . . . . . . . . . . . . 18 8.3 Anonymity . . . . . . . . . . . . . . . . . . . . . . . . 18 8.4 Denial-of-Service Attacks . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9.1 IANA Registration of 'Resource-Priority' and 'Accept-Resource-Priority' Header Fields . . . . . . . . . 19 9.2 IANA Registration for Option Tag resource-priority . . . . 19 9.3 IANA Registration for Response Code 417 . . . . . . . . . 19 9.4 IANA Namespace and Priority Registrations . . . . . . . . 20 9.5 Initial Namespace Registrations . . . . . . . . . . . . . 21 9.5.1 Namespace drsn . . . . . . . . . . . . . . . . . . . . 21 9.5.2 Namespace dsn . . . . . . . . . . . . . . . . . . . . 21 9.5.3 Namespace ets . . . . . . . . . . . . . . . . . . . . 21 9.5.4 Namespace q735 . . . . . . . . . . . . . . . . . . . . 22 9.5.5 Namespace wps . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 11.2 Informative References . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . 26 Schulzrinne & Polk Expires February 27, 2005 [Page 2] Internet-Draft SIP Resource Priority August 2004 1. Introduction During emergencies, communications resources including telephone circuits, IP bandwidth and gateways between the circuit-switched and IP networks may become congested. Congestion can occur due to heavy usage, loss of resources caused by the natural or man-made disaster and attacks on the network during man-made emergencies. This congestion may make it difficult for persons charged with emergency assistance, recovery or law enforcement to coordinate their efforts. As IP networks become part of converged or hybrid networks along with public and private circuit-switched (telephone) networks, it becomes necessary to ensure that these networks can assist during such emergencies. Also, users may want to interrupt their lower-priority communications activities and dedicate their end system resources to the high-priority communications attempt if a high-priority communications request arrives at their end system. There are many IP-based services that can assist during emergencies. This memo only covers real-time communications applications involving the Session Initiation Protocol (SIP) [RFC3261], including voice-over-IP, multimedia conferencing, instant messaging and presence. SIP applications may involve at least five different resources that may become scarce and congested during emergencies. These resources include gateway resources, circuit-switched network resources, IP network resources, receiving end system resources and SIP proxy resources. IP network resources are beyond the scope of SIP signaling and are therefore not considered here. In order to improve emergency response, it may become necessary to prioritize access to SIP-signaled resources during periods of emergency-induced resource scarcity. We call this "resource prioritization". The mechanism itself may well be in place at all times, but only materially affect call handling during times of resource scarcity. Currently, SIP does not include a mechanism that allows a request originator to indicate to a SIP element that it wishes the request to invoke such resource prioritization. To address this need, this document adds a SIP protocol element that labels certain SIP requests. This document defines (Section 3) a new SIP [RFC3261] header field for communications resource priority, called 'Resource-Priority' This Schulzrinne & Polk Expires February 27, 2005 [Page 3] Internet-Draft SIP Resource Priority August 2004 header field MAY be used by SIP user agents, including General Switched Telephone Network (GSTN) gateways and terminals, and SIP proxy servers to influence their treatment of SIP requests, including the priority afforded to GSTN calls. For GSTN gateways, the behavior translates into analogous schemes in the GSTN, for example the ITU Recommendation Q.735.3 [Q.735.3] prioritization mechanism, in both the GSTN-to-IP and IP-to-GSTN directions. ITU Recommendation I.255.3 [I.255.3] is another example. The 'Resource-Priority' header field may be used in several situations. A SIP request with such an indication can be treated differently in these situations: 1. The request can be given elevated priority for access to GSTN gateway resources such as trunk circuits. 2. The request can interrupt lower-priority requests at a user terminal, such as an IP phone. 3. The request can carry information from one multi-level priority domain in the telephone network, e.g., using the facilities of Q.735.3 [Q.735.3], to another, without the SIP proxies themselves inspecting or modifying the header field. 4. In SIP proxies and back-to-back user agents, requests of higher priorities may displace existing signaling requests or bypass GSTN gateway capacity limits in effect for lower priorities. This header field is related to, but differs in semantics from, the 'Priority' header field (RFC 3261 [RFC3261], Section 20.26). The 'Priority' header field describes the importance that the SIP request should have to the receiving human or its agent. For example, that header may be factored into decisions about call routing to mobile devices and assistants and call acceptance when the call destination is busy. The 'Priority' header field does not affect the usage of GSTN gateway or proxy resources, for example. In addition, any User Agent Client (UAC) can assert any 'Priority' value, while access to resource priority values is subject to authorization. While the 'Resource-Priority' header does not directly influence the forwarding behavior of IP routers or the use of communications resources such as packet forwarding priority, procedures for using this header to cause such influence may be defined in other documents. Existing implementations of RFC 3261 that do not participate in the resource priority mechanism follow the normal rules of RFC 3261, Section 8.2.2: "If a UAS does not understand a header field in a request (that is, the header field is not defined in this specification or in any supported extension), the server MUST ignore that header field and continue processing the message." Thus, the use Schulzrinne & Polk Expires February 27, 2005 [Page 4] Internet-Draft SIP Resource Priority August 2004 of this mechanism is wholly invisible to existing implementations unless the request includes the Require header field with the resource-priority option tag. The mechanism described here can be used for emergency preparedness in emergency telecommunications systems, but is only a small part of an emergency preparedness network and is not restricted to such use. The mechanism aims to satisfy the requirements in [RFC3487]. It is structured so that it works in all SIP and Real-Time Transport Protocol (RTP) [RFC3550] transparent networks defined in [RFC3487]. In such networks, all network elements and SIP proxies let valid SIP requests pass through unchanged. This is important since it is likely that this mechanism will often be deployed in networks where the edge networks are unaware of the resource priority mechanism and provide no special privileges to such requests. The request then reaches a GSTN gateway or set of SIP elements that are aware of the mechanism. For conciseness, we refer to SIP proxies and user agents (UAs) that act on the 'Resource-Priority' header field as RP actors. We define the header field syntax in Section 3 and then describe the behavior of user agents and proxies in Section 4.3 through Section 4.5. Section 6 briefly describes how this feature affects existing systems that do not support it. Third-party authentication is discussed in Section 5, while general security issues are enumerated in Section 8. This specification does not propose any new SIP security mechanisms. Examples can be found in Section 7. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations. 3. The Resource-Priority and Accept-Resource-Priority SIP Header Fields This document defines the 'Resource-Priority' and 'Accept-Resource-Priority' SIP header fields. The SIP element behavior is described for user agent clients (UACs) in Section 4.3, for UAS in Section 4.4 and for SIP proxy servers in Section 4.5. Schulzrinne & Polk Expires February 27, 2005 [Page 5] Internet-Draft SIP Resource Priority August 2004 3.1 The 'Resource-Priority' Header Field The 'Resource-Priority' header field marks a SIP request as desiring prioritized resource access, as described in the introduction. In responses, the 'Resource-Priority' header fields indicates the actual resource priority that was granted to the request. While it is likely that responses contain the same 'Resource-Priority' header field value as the requests, local policy MAY call for the UAS to insert no header field or a different value. There is no requirement that all requests within a SIP dialog or session use the 'Resource-Priority' header field. Again, local policy dictates the appropriate behavior; thus, implementations MUST be configurable accordingly. The syntax of the 'Resource-Priority' header field is described below. The "token-nodot" production is copied from [RFC3265]. Resource-Priority = "Resource-Priority" HCOLON r-value *(COMMA r-value) r-value = namespace "." r-priority namespace = token-nodot r-priority = token-nodot token-nodot = 1*( alphanum / "-" / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" ) An example 'Resource-Priority' header field is shown below: Resource-Priority: q735.1, dsn.flash The 'Resource-value' parameter in the 'Resource-Priority' header indicates the resource priority desired by the request originator. Since a request may traverse multiple administrative domains with multiple different namespaces, it is necessary to be able to enumerate several different namespaces. However, each namespace MUST NOT appear more than once in a SIP message. Each resource value is formatted as 'namespace' '.' 'priority value'. The value is drawn from the namespace identified by the 'namespace' token. Namespaces and priorities are case-insensitive ASCII. Each namespace has at least one priority value. Namespaces and priority values within each namespace MUST be registered with IANA (Section 9). Initial namespace registrations are described in Section 9.5. There may be multiple resource values or, equivalently, multiple 'Resource-Priority' header field instances. Schulzrinne & Polk Expires February 27, 2005 [Page 6] Internet-Draft SIP Resource Priority August 2004 3.2 The 'Accept-Resource-Priority' Header Field The 'Accept-Resource-Priority' response header field enumerates the resource values a SIP user agent server is willing to accept. The syntax of the 'Accept-Resource-Priority' header field is as follows: Accept-Resource-Priority = "Accept-Resource-Priority" HCOLON [r-value *(COMMA r-value)] An example is given below: Accept-Resource-Priority: dsn.flash-override, dsn.flash, dsn.immediate, dsn.priority, dsn.routine 3.3 Usage of the 'Resource-Priority' and 'Accept-Resource-Priority' Header Fields The following table extends the values in Table 2 of RFC3261 [RFC3261]. (The PRACK method, labeled as PRA, is defined in [RFC3262], the SUBSCRIBE (labeled SUB) and NOTIFY (labeled NOT) methods in [RFC3265], the UPDATE (UPD) method in [RFC3311], the MESSAGE (MSG) method in [RFC3428], the REFER (REF) method in [RFC3515], the INFO (INF) method in [RFC2976], and the PUBLISH (PUB) method in [I-D.ietf-sip-publish].) Header field where proxy INV ACK CAN BYE REG OPT PRA ---------------------------------------------------------------- Resource-Priority R amdr o o o o o o o Resource-Priority 200 - o - o o o o o Accept-Resource-Priority 200 - o o o o o o o Accept-Resource-Priority 417 - m - m m m m m Accept-Resource-Priority 420 - o - o o o o o Header field where proxy SUB NOT UPD MSG REF INF PUB ---------------------------------------------------------------- Resource-Priority R amdr o o o o o o o Resource-Priority 200 - o o o o o o o Accept-Resource-Priority 200 - o o o o o o o Accept-Resource-Priority 417 - m m m m m m m Accept-Resource-Priority 420 - o o o o o o o Other request methods MAY define their own handling rules; unless otherwise specified, recipients MAY ignore these header fields. 'Accept-Resource-Priority' MUST be returned in 420 (Not Supported) responses marked as 'o' in table above if the element implements the resource priority mechanism with some other namespaces or priority values, but does not implement the particular namespace or priority Schulzrinne & Polk Expires February 27, 2005 [Page 7] Internet-Draft SIP Resource Priority August 2004 value contained in the request. While all methods listed above allow the optional use of the 'Resource-Priority' header fields, only request methods that start a dialog or deliver content, such as MESSAGE, are likely to benefit from this mechanism and other methods SHOULD NOT use them. This consideration also applies to methods not listed above. 3.4 The 'resource-priority' Option Tag This document also defines the "resource-priority" option tag. The behavior is described in Section 4.2.2 and the IANA registration is in Section 9.2. 4. Behavior of SIP Elements that Receive Prioritized Requests 4.1 General Rules All SIP user agent servers and proxy servers that receive SIP requests share certain common behavior, which we describe below. Behavior that is specific to user agent servers is covered in Section 4.4, while Section 4.5 deals with proxy behavior. A SIP element supporting this specification MUST be able to interpret the 'Resource-Priority' header field in INVITE, ACK, PRACK [RFC3262], MESSAGE [RFC3428], UPDATE [RFC3311], SUBSCRIBE [RFC3265] and NOTIFY [RFC3265] requests, if it supports a particular request. (This does not imply that all elements supporting this specification need to support all of these request methods.) In all such requests, the priority MAY influence the order in which requests are handled and MUST influence the resources, such as circuits, bandwidth or memory, allocated based on the request. For example, for SUBSCRIBE, a higher-priority request may get preferential treatment if storage or bandwidth for notifications are scarce, possibly displacing a lower-priority subscription. (As always, the precise behavior is defined by a namespace definition, or, if left unspecified, by an implementation or configuration.) A SIP element MAY ignore the header field in other requests unless the request definition defines behavior for the particular method. If a request contains multiple valid namespace and priority values, the request is treated according to the highest priority value which the recipient supports and authorizes. The total ordering of priorities between different namespaces is defined by local policy. An OPTIONS request can be used to determine if an element supports the mechanism. A compliant implementation MUST return a Schulzrinne & Polk Expires February 27, 2005 [Page 8] Internet-Draft SIP Resource Priority August 2004 'Accept-Resource-Priority' header field in OPTIONS responses enumerating all valid resource values. An implementation MAY reveal this capability only to authorized UACs. (Note that an overloaded UAS may not be able to provide this information at all times.) Note that according to RFC 3261, proxies reached with a Max-Forwards value of zero answer the OPTIONS request, allowing a UAC to discover the capabilities of both proxy and user agent servers. 4.2 Error Conditions 4.2.1 Known Namespace and Priority Value Two error conditions can occur if a request reaches an element that supports the namespace and resource priority. Elements receiving requests with namespaces or priority values that they do not understand act according to the rules in the next section. Insufficient authorization: If the element receives a request with a namespace and priority value it recognizes, but the originator is not authorized for that level of service, the element MUST return a 403 (Forbidden) response. Insufficient resources: If there are insufficient resources at an element for a given priority, a request might be delayed or refused, depending on local policy or the definition of the namespace. If it is refused, the element returns a 503 (Service Unavailable) response. The response MAY also include a 'Warning' header with warning code 370 (Insufficient Bandwidth) if the request failed due to insufficient capacity for the media streams, rather than insufficient signaling capacity. The 503 (Service Unavailable) response provides sufficient indication to the originator to re-attempt with a higher appropriate resource priority or to add a resource priority indication, if authorized. 4.2.2 Handling Unknown Namespaces and Priority Values When handling requests with unknown namespaces or priority values, elements can operate in two modes, "strict" and "loose", identified by the presence or absence of a 'Require' header field with the 'Resource-Priority' option tag. If the request includes a 'Require' header field with the 'Resource-Priority' option tag, a UAS MUST follow the strict-mode rules, otherwise UAS and proxies MUST operate in loose mode. Both are described in detail below. The use of the 'resource-priority' option tag in 'Proxy-Require' header field is NOT RECOMMENDED. Schulzrinne & Polk Expires February 27, 2005 [Page 9] Internet-Draft SIP Resource Priority August 2004 4.2.2.1 Strict Mode Following standard SIP behavior (Section 8.2.2.3 of [RFC3261]), a UAS operating in strict mode MUST reject the request with response code 420 (Bad Extension) if it does not support the resource priority option tag. For example, a gateway that is unaware of a resource priority namespace might accept a request at non-elevated priority, but then the request could later be preempted by other requests. Also, use of the 'Require' restriction ensures that in parallel forking, only branches that support the resource priority mechanism succeed. In strict mode, an element that receives a request with a 'Resource-Priority' header field containing one or more namespace or priority values that it does not implement rejects the request with status code 417 (Unknown Resource-Priority). Implementations MUST, as a configurable option, support returning a 'Accept-Resource-Priority' header field enumerating all the resource values that the server is willing to process, but network operators MAY disable returning this information. Note that the user may not be authorized to use all of these resource values. Strict mode is particularly useful for operational testing of systems supporting resource priority, as otherwise it might be difficult to detect under non-overload conditions whether an element supports the functionality or not. 4.2.2.2 Loose Mode In loose mode, unknown priority values or namespaces are ignored; the request is treated as if these values were not included. If there are no valid priority values or namespaces, the request is treated as if it had no 'Resource-Priority' header field. Thus, no 417 (Unknown Resource-Priority) is generated. 4.3 User Agent Client Behavior SIP UACs supporting this specification MUST be able to generate the 'Resource-Priority' header field for requests that require elevated resource access priority. If the request is returned with 417 (Unknown Resource-Priority), the UAC MAY retry the request with a different set of namespace/priority combinations, drawing from the values returned by the 'Accept-Resource-Priority' header field in the response. Schulzrinne & Polk Expires February 27, 2005 [Page 10] Internet-Draft SIP Resource Priority August 2004 4.4 User Agent Server Behavior If the UAS understands the resource value, but refuses to honor the request with elevated priority for this particular user, it returns the 403 (Forbidden) response code. It MAY include the list of resource values that the user is allowed to use in the 'Accept-Resource-Priority' response header field. The lookup of the authorized values may take significant resources since it may involve an AAA interaction. Thus, it seems imprudent to require that the list is customized to the user. In general, legitimate users know their highest resource value that they are entitled to. The precise effect of the 'Resource-Priority' indication depends on the type of UAS, the namespace and local policy. For example, a circuit-switched telephony gateway might move requests with elevated priority to the front of the queue of requests waiting for outbound lines, it may utilize additional resources or it may preempt existing calls. For a terminal, such as a SIP phone, requests with elevated priority might trigger a special alert tone or preempt other, lower-priority existing calls. The generic protocol mechanism described here does not mandate the particular element behavior, but namespace definitions, such as the ones in Section 9.5, MUST describe the desired behavioral properties of user agents and proxy servers. 4.5 Proxy Behavior SIP proxies MAY ignore or inspect the 'Resource-Priority' header field. SIP proxies MAY reject any unauthenticated request bearing the header field. If there are multiple namespace or priority choices available to the user agent client, a proxy MAY return the request with an appropriate 'Accept-Resource-Priority' header field. Details are a matter of local policy. If the header fields are protected via S/MIME encapsulation in a SIP message fragment [RFC3420], the 'Resource-Priority' value cannot be changed or added by proxies. If no S/MIME is used, SIP proxies MAY downgrade or upgrade the 'Resource-Priority' of a request or insert a new 'Resource-Priority' header if allowed by local policy. This behavior is similar to that for any header field, as a UA can decide to reject a request for the presence, absence or value of any information in the request. The session policy mechanism does Schulzrinne & Polk Expires February 27, 2005 [Page 11] Internet-Draft SIP Resource Priority August 2004 not fit well, as user agents may not have a choice in the namespace or priority available to them, there are no privacy concerns and the resource priority mechanism does not involve message bodies or session descriptions. If a stateful proxy has authorized a particular resource priority level and if it offers differentiated treatment to responses containing resource priority levels, the proxy SHOULD ignore any higher value contained in responses, to avoid that colluding user agents artificially raise the priority level. It is unlikely that the resource priority value in responses will have any influence on response handling. A SIP proxy MAY use the 'Resource-Priority' indication in its routing decisions, e.g., to retarget to a SIP node or SIP URI that is reserved for a particular resource priority. There do not appear to be any special considerations when forking requests containing a resource priority indication. Otherwise, the proxy behavior is the same as for user agent servers Section 4.4). 5. Third-Party Authentication In some case, the RP actor may not be able to authenticate the requestor or determine whether an authenticated user is authorized to make such a request. In these circumstances, the SIP entity may avail itself of general SIP mechanisms that are not specific to this application. The authenticated identity management mechanism [I-D.ietf-sip-authid-body] allows a third party to verify the identity of the requestor and certify this towards an RP actor. In networks with mutual trust, the SIP asserted identity mechanism [RFC3325] can help the RP actor determine the identity of the requestor. 6. Backwards Compatibility The resource priority mechanism described in this document is fully backwards compatible with SIP systems following [RFC3261]. Systems that do not understand the mechanism can only deliver standard, not elevated, service priority. User agent servers and proxies can ignore any 'Resource-Priority' header field just like any other unknown header field and then treat the request like any other request. Naturally, the request may still succeed. Introducing 'Require' or 'Proxy-Require' would not help backwards Schulzrinne & Polk Expires February 27, 2005 [Page 12] Internet-Draft SIP Resource Priority August 2004 compatibility, as systems that do not support these mechanism are no better off rejecting the request due to feature failure. Since the intent of resource priority indications is to increase the probability of call completion, adding failure modes appears counterproductive. 7. Examples The SDP message body and the BYE and ACK exchanges are the same as in RFC 3665 [RFC3665] and omitted for brevity. 7.1 Simple Call User A User B | | | INVITE F1 | |----------------------->| | 180 Ringing F2 | |<-----------------------| | | | 200 OK F3 | |<-----------------------| | ACK F4 | |----------------------->| | Both Way RTP Media | |<======================>| | | In this scenario, User A completes a call to User B directly. The call from A to B is marked with a resource priority indication. F1 INVITE User A -> User B INVITE sip:UserB@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: BigGuy ;tag=9fxced76sl To: LittleGuy Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Resource-Priority: dsn.flash Contact: Content-Type: application/sdp Content-Length: ... ... F2 180 Ringing User B -> User A Schulzrinne & Polk Expires February 27, 2005 [Page 13] Internet-Draft SIP Resource Priority August 2004 SIP/2.0 180 Ringing Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: BigGuy ;tag=9fxced76sl To: LittleGuy ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Resource-Priority: dsn.flash Contact: Content-Length: 0 F3 200 OK User B -> User A SIP/2.0 200 OK Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: BigGuy ;tag=9fxced76sl To: LittleGuy ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Resource-Priority: dsn.flash Contact: Content-Type: application/sdp Content-Length: ... ... 7.2 Receiver Does Not Understand Namespace In this example, the receiving UA does not understand the "dsn" namespace and thus returns a 417 (Unknown Resource-Priority) status code. We omit the message details for messages F5 through F7 since they are essentially the same as in the first example. Schulzrinne & Polk Expires February 27, 2005 [Page 14] Internet-Draft SIP Resource Priority August 2004 User A User B | | | INVITE F1 | |----------------------->| | 417 R-P failed F2 | |<-----------------------| | ACK F3 | |----------------------->| | | | INVITE F4 | |----------------------->| | 180 Ringing F5 | |<-----------------------| | 200 OK F6 | |<-----------------------| | ACK F7 | |----------------------->| | | | Both Way RTP Media | |<======================>| F1 INVITE User A -> User B INVITE sip:UserB@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: BigGuy ;tag=9fxced76sl To: LittleGuy Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Resource-Priority: dsn.flash Contact: Content-Type: application/sdp Content-Length: ... ... F2 417 Resource-Priority failed User B -> User A SIP/2.0 417 Resource-Priority failed Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: BigGuy ;tag=9fxced76sl To: LittleGuy ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Schulzrinne & Polk Expires February 27, 2005 [Page 15] Internet-Draft SIP Resource Priority August 2004 Accept-Resource-Priority: q735.0, q735.1, q735.2, q735.3, q735.4 Contact: Content-Type: application/sdp Content-Length: 0 F3 ACK User A -> User B ACK sip:UserB@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bd5 Max-Forwards: 70 From: BigGuy ;tag=9fxced76sl To: LittleGuy ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 ACK Content-Length: 0 F4 INVITE User A -> User B INVITE sip:UserB@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: BigGuy ;tag=9fxced76sl To: LittleGuy Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 INVITE Resource-Priority: q735.3 Contact: Content-Type: application/sdp Content-Length: ... ... 8. Security Considerations 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 gateway, cause additional congestion during PSTN during emergencies or deny service to legitimate users. While the indication itself does not have to provide separate authentication, any SIP request carrying such information has higher authentication requirements than regular requests. 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. Schulzrinne & Polk Expires February 27, 2005 [Page 16] Internet-Draft SIP Resource Priority August 2004 All user agents and proxy servers which support this extension MUST implement SIP over TLS [RFC3546] and 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 which support this extension SHOULD also implement S/MIME [RFC2633] as described in Section 23 of RFC 3261 to allow for signing and verification of signatures over requests which use this extension. 8.1 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, 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 [I-D.ietf-sipping-trait-authz] "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 beyond the identity of the caller, such as the requested destination. Namespaces MAY also Schulzrinne & Polk Expires February 27, 2005 [Page 17] Internet-Draft SIP Resource Priority August 2004 impose particular authentication or authorization consideration that are stricter than the baseline described here. 8.2 Confidentiality and Integrity Calls which 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 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 that encapsulation is 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). 8.3 Anonymity Some users may wish to remain anonymous to the request destination. Anonymity for requests with resource priority is no different than 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 Schulzrinne & Polk Expires February 27, 2005 [Page 18] Internet-Draft SIP Resource Priority August 2004 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]. 8.4 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 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. 9. IANA Considerations 9.1 IANA Registration of 'Resource-Priority' and 'Accept-Resource-Priority' Header Fields [NOTE TO RFC EDITOR: Replace RFC XXXX with RFC number of this document.] The following is the registration for the 'Resource-Priority' header field: RFC number: XXXX Header name: 'Resource-Priority' Compact form: none The following is the registration for the 'Accept-Resource-Priority' header field: RFC number: XXXX Header name: Accept-Resource-Priority Compact form: none 9.2 IANA Registration for Option Tag resource-priority RFC number: XXXX Name of option tag: 'resource-priority' Descriptive text: Indicates or requests support for the resource priority mechanism. 9.3 IANA Registration for Response Code 417 Schulzrinne & Polk Expires February 27, 2005 [Page 19] Internet-Draft SIP Resource Priority August 2004 RFC number: XXXX Response code: 417 Default reason phrase: Unknown Resource-Priority 9.4 IANA Namespace and Priority Registrations Additional namespaces and priority values MUST be registered with IANA. Within each namespace, the registration may indicate the relative precedence levels, expressed as an ordered list. New labels should not be added to existing namespaces. The registration MUST describe, in the registration itself or by reference, how SIP elements should treat requests from that namespace, e.g., whether preemption or only preferential queueing are allowed. A reference to a stable external document, e.g., by the International Telecommunication Union, other SDOs or national regulatory bodies, suffices. An expert review, by an expert designated by the Transport Area Director or designate, is required. Namespaces do not describe how they relate to other existing namespaces, as each namespace is independent of other registrations. Below is a template for the registration of a new namespace: Namespace: Designation of the namespace, according to the BNF 'namespace' in Section 3. Description: Description of the use and application of this particular namespace. Documentation: If applicable, reference to a document describing the namespace in more detail. Organization: If applicable, organization defining this namespace. (For example, an IETF standards-track RFC could also define a namespace, not just an external organization.) Policy: Either if not defined normatively elsewhere or for informative purposes, this element describes how a SIP element handles requests containing priority values with this namespace. There are many possible behaviors that cannot be exhaustively anticipated. Three common behaviors are preemption, precedence and threshold-exemption. Preemption means that a request with greater priority can displace an existing request with lower priority that is already in progress. Precedence means that a higher-priority request assumes a position in the queue ahead of a lower-priority request, but any in-progress request is not affected by its arrival. In addition, systems with preemption MAY specify whether requests that cannot obtain resources immediately are queued or rejected immediately. Threshold-exemption allows higher-priority calls to access resources, such as circuits, that are unavailable to lower-priority calls, e.g., because they are held in reserve. If the namespace does not define a particular Schulzrinne & Polk Expires February 27, 2005 [Page 20] Internet-Draft SIP Resource Priority August 2004 policy, the term 'implementation-defined' should be used. Priority values (least to greatest): A list of priority values, ordered from least to highest priority. 9.5 Initial Namespace Registrations 9.5.1 Namespace drsn Namespace: drsn Description: United States Defense Red Switched Network. Organization: United States Department of Defense, Defense Information Systems Agency (DISA). Policy: Preemption with rejection. Priority values (least to greatest): "routine", "priority", "immediate", "flash", "flash-override", "flash-override-override" 9.5.2 Namespace dsn Namespace: dsn Description: United States Defense Switched Network. The values are adopted from RFC 791 [RFC0791], omitting the levels "critic-ecp", "network control" and "internetwork control", as these are inappropriate here. Documentation: ANSI T1.619, Section B1 Organization: United States Department of Defense, Defense Information Systems Agency (DISA). Policy: Preemption with rejection. Priority values (least to greatest): "routine", "priority", "immediate", "flash", "flash-override" 9.5.3 Namespace ets Namespace: ets Description: Emergency Telecommunications Service (ETS) specifies Signaling System No. 7 (SS7) and Bearer Independent Call Control (BICC) protocols for (Government) Emergency Telecommunications Service (ETS) for authorized users with national security and emergency preparedness responsibilities. The namespace "ets" supports interworking with ATIS.ETS (or equivalent) PSTN, including ISDN, entities. This interworking allows, for example, carrying signaling information between ATIS.ETS entities without loss of information. One or both of the SIP endpoints might be PSTN gateways. The namespace "ets" allows, based on policy, to provide priority treatment in processing and allocating resources to call and session requests marked with this namespace. Schulzrinne & Polk Expires February 27, 2005 [Page 21] Internet-Draft SIP Resource Priority August 2004 Documentation: ATIS.ETS Organization: Alliance for Telecommunications Industry Solutions (ATIS) Policy: Implementation-defined. Priority values (least to greatest): "4", "3", "2", "1", "0" 9.5.4 Namespace q735 Namespace: q735 Description: ITU Q.735.3 describes multi-level precedence and preemption in SS7. The namespace "q735" supports interworking with Q.735.3 (or equivalent) GSTN (ISDN) entities; this allows, for example, carrying information between Q.735.3 entities without loss of information. One or both of the SIP endpoints might be PSTN gateways. Documentation: Q.735.3 [Q.735.3] Organization: ITU-T Policy: Precedence. Priority values (least to greatest): "4", "3", "2", "1", "0" 9.5.5 Namespace wps Namespace: wps Description: Description: Wireless Priority Service (WPS) extends (Government) Emergency Telecommunications Service (ETS)-like priority treatment to authorized users with national security and emergency preparedness responsibilities who use mobile terminals to place voice or voice-band data calls. The namespace "wps" supports interworking with ATIS.TR.WPS (or equivalent) PSTN, including ISDN, entities. This interworking allows, for example, carrying signaling information between ATIS.TR.ETS entities without loss of information. One or both of the SIP endpoints might be PSTN gateways. The namespace "wps" allows, based on policy, to provide priority treatment in processing and allocating resources to call or session requests, including air interface, labeled with this namespace. Documentation: ATIS.TR.ETS Organization: Alliance for Telecommunications Industry Solutions (ATIS) Policy: Implementation-defined. Priority values (least to greatest): "4", "3", "2", "1", "0" 10. Acknowledgments Ben Campbell, Janet Gunn, Paul Kyzivat, Rohan Mahy, Mike Pierce and Samir Srivastava provided helpful comments. Martin Dolly, An Nguyen and Niranjan Sandesara assisted with the Schulzrinne & Polk Expires February 27, 2005 [Page 22] Internet-Draft SIP Resource Priority August 2004 sections on the NCS namespaces. 11. References 11.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. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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., "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. 11.2 Informative References [I-D.ietf-ieprep-framework] Carlberg, K., Brown, I. and C. Beard, "Framework for Schulzrinne & Polk Expires February 27, 2005 [Page 23] Internet-Draft SIP Resource Priority August 2004 Supporting ETS in IP Telephony", draft-ietf-ieprep-framework-09 (work in progress), April 2004. [I-D.ietf-sip-authid-body] Peterson, J., "SIP Authenticated Identity Body (AIB) Format", draft-ietf-sip-authid-body-03 (work in progress), May 2004. [I-D.ietf-sip-publish] Niemi, A., "An Event State Publication Extension to the Session Initiation Protocol (SIP)", draft-ietf-sip-publish-04 (work in progress), May 2004. [I-D.ietf-sipping-trait-authz] Peterson, J., "Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)", draft-ietf-sipping-trait-authz-00 (work in progress), February 2004. [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. [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, 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. [RFC3324] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, 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. [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. Schulzrinne & Polk Expires February 27, 2005 [Page 24] Internet-Draft SIP Resource Priority August 2004 [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. Authors' Addresses Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US Phone: +1 212 939 7042 EMail: hgs@cs.columbia.edu URI: http://www.cs.columbia.edu James Polk Cisco 2200 East President George Bush Turnpike Richardson, TX 75082 US EMail: jmpolk@cisco.com Schulzrinne & Polk Expires February 27, 2005 [Page 25] Internet-Draft SIP Resource Priority August 2004 Intellectual Property Statement 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 IETF's procedures with respect to rights in IETF 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 attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Schulzrinne & Polk Expires February 27, 2005 [Page 26]