Internet Engineering Task Force Internet Draft H. Schulzrinne Columbia U. draft-schulzrinne-ieprep-resource-req-01.txt July 30, 2002 Expires: January 2003 Requirements for Resource Priority Mechanisms for the Session Initiation Protocol STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session Initiation Protocol (SIP). 1 Introduction During emergencies, communications resources including telephone circuits, IP bandwidth and gateways between the circuit-switched and IP networks may become congested due to heavy usage, loss of resources caused by the disaster and attack during man-made emergencies, making it difficult for persons charged with emergency assistance, recovery or law enforcement to coordinate their efforts. H. Schulzrinne [Page 1] Internet Draft RP Requirements July 30, 2002 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. There are many IP-based services that can assist during emergencies. This memo only covers requirements for real-time communications applications involving SIP, including voice-over-IP, multimedia conferencing and instant messaging/presence. Almost any other communications application may be useful during emergency situations. In general, these applications may benefit from network resource prioritization and thus some of the remarks and requirements may apply. However, detailed discussion and requirements are left to other documents. This document takes no position as to which mode of communication is preferred during an emergency, as such discussion appears to be of little practical value. Based on past experience, real-time communications is likely to be an important component of any overall suite of applications, particularly for coordination of emergency-related efforts. As we will describe in detail below, such SIP applications involve at least five different resources that may become scarce and congested during emergencies. In order to improve emergency response, it may become necessary to prioritize access to such resources during periods of emergency-induced resource scarcity. We call this "resource prioritization". This document describes requirements rather than possible existing or new mechanisms. Although it is scoped to deal with SIP-based applications, this should not be taken to imply that mechanisms have to be SIP protocol features such as header fields, methods or URI parameters. The document is organized as follows. In Section 2, we explain core technical terms and acronyms that are used throughout the document. [Some of these may migrate to a terminology document.] Section 3 describes the five types of resources that may be subject to resource prioritization. Section 4 enumerates four network hybrids that determine which of these resources are relevant. Since the design choices may be constrained by the assumptions placed on the IP network, Section 5 attempts to classify networks into categories according to the restrictions placed on modifications and traffic classes. Section 6 summarizes some general requirements that try to achieve generality and feature-transparency across hybrid networks. Providing resource priority entails complex implementation choices, so that a single priority mechanism is actually an algorithm that manages queues, resource consumption and existing resource uses. Even H. Schulzrinne [Page 2] Internet Draft RP Requirements July 30, 2002 within a single administrative domain, the combination of mechanisms is likely to vary. Since it will also depend on the interaction of different policies, it appears inappropriate to have SIP applications specify the precise mechanisms. Section 7 discusses the call-by-value (specification of mechanisms) and call-by-reference (invoke labeled policy) distinction. Request routing is a core component of SIP, covered in Section 8. Since this is a major source of confusion due to similar names, Section 9 attempts to distinguish emergency call services placed by civilians from the topic of this document. The most challenging component of a resource prioritization mechanism is likely to be security (Section 10). Without adequate security mechanisms, resource priority may cause more harm than good, so that the section attempts to enumerate some of the specific threats present when resource prioritization is being employed. 2 Terminology CN: Circuit-switched network, encompassing both private (closed) networks and the public switched telephone network (PSTN). EPCC: Enhanced probability of call completion; indicates a mechanism that improves the probability that certain calls reach their intended destination. Call completion encompasses successful application-layer (SIP) signaling as well as successful acquisition of bandwidth and other necessary network resources. ETS: Emergency telecommunications service, identifying a communications service to be used during large-scale emergencies that allows authorized individuals to communicate. Such communication may reach end points either within a closed network or any endpoint on the CN or the Internet. The communication service may use voice, video, text or other multimedia streams. Request: In this document, we define "request" as any SIP request. This includes call setup requests, instant message requests and event notification requests. 3 Resources Prioritized access to at least five resource types may be useful: Gateway resources: The number of channels (trunks) on a CN H. Schulzrinne [Page 3] Internet Draft RP Requirements July 30, 2002 gateway is finite. A resource prioritization mechanism may prioritize access to these channels, by priority queuing or preemption. CN resources: Resources in the CN itself, away from the access gateway, may be congested. This is the domain of traditional prioritization mechanism such as MLPP and GETS, where circuits are granted to ETS communications based on queueing priority or preemption. Specifying CN behavior is beyond the scope of this document, but as noted below, a central requirement is to be able to invoke all such behaviors from an IP endpoint. IP network resources: SIP may initiate voice and multimedia sessions. In many cases, audio and video streams are inelastic and have tight delay and loss requirements. Under conditions of IP network overload, ETS applications may not be able to obtain sufficient bandwidth in a best-effort network. It is thus desirable to provide such applications with more than their (TCP-like) fair share of bandwidth, while guaranteeing that only ETS applications can make use of these privileges (see Section 10). Bandwidth used for SIP signaling itself may be subject to prioritization. Receiving end system resources: If the receiving end system can only manage a finite number of sessions, a prioritized call may need to preempt an existing call or indicate to the callee that a high-priority call is waiting. (The precise user agent behavior is beyond the scope of this document and considered a matter of policy and implementation.) Such terminating services may be needed to avoid overloading, say, an emergency coordination center. However, other mechanisms beyond prioritization, e.g., random request dropping by geographic origin, need to be employed if the number of prioritized calls exceeds the terminating capacity. Such algorithms are beyond the scope of this memo. SIP proxy resources: While SIP proxies often have large request handling capacities, their capacity is likely to be smaller than their access network bandwidth. (This is true in particular since different SIP requests consume vastly different amounts of proxy computational resources, depending on whether they invoke external services, scripts, etc. Thus, avoiding proxy overload by restricting H. Schulzrinne [Page 4] Internet Draft RP Requirements July 30, 2002 access bandwidth is likely to lead to inefficient utilization of the proxy.) Thus, proxies may need to silently drop SIP requests under overload or reject requests, with overload indication. There is no requirement that a single mechanism be used for all four resources. 4 Hybrid Networks We consider four types of combinations of IP and CN networks. IP only: Both request originator and destination are on an IP network, without intervening CN-IP gateways. Here, any SIP request could be subject to prioritization. IP-to-CN: The request originator is in the IP network, while the callee is in the CN. Clearly, this model only applies to SIP-originated phone calls, not generic SIP requests such as those supporting instant messaging services. CN-to-IP: A call originates in the CN and terminates, via a gateway, in the IP network. CN-IP-CN: This is a concatenation of the two previous ones. It is worth calling out specifically to note that the two CN sides may use different signaling protocols. Also, the originating CN endpoint and the gateway to the IP network may not know the nature of terminating CN. Thus, encapsulation of originating CN information is insufficient. It is worth emphasizing that CN-to-IP gateways are unlikely to know whether the final destination is in the IP network, the CN or, via SIP forking, in both. These models differ in the type of controllable resources. Items marked as (x) are beyond the scope of this document, as the resource is in the CN. Hybrid Gateway CN IP recv. ________________________________ IP-only x x IP-to-CN x x x (x) CN-to-IP x x x CN-IP-CN x x x (x) H. Schulzrinne [Page 5] Internet Draft RP Requirements July 30, 2002 5 Network Models There are at least four IP network models that influence the requirements for resource priority. Each model inherits the restrictions of the model above it. Full control: In a fully controlled network, an ETS application can use any protocol carried in IP packets and modify the behavior of existing protocols. As an example, if an ETS agency owns the IP network, it can add traffic shaping or scheduling or support for a resource reservation protocol to routers. Transparent: In a transparent network, an ETS application can rely on the network to forward all valid IP packets, however, the ETS application cannot modify network elements. Commercial ISP offer transparent networks as long as they do not filter certain types of packets. Networks employing firewalls, NATs and "transparent" proxies are not transparent. Sometimes, these types of networks are also called common-carrier networks since they carry IP packets without concern as to their content. SIP/RTP transparent: Networks with SIP-level control allow users to place and receive SIP calls. The network allows ingress and egress for all valid SIP messages, possibly subject to authentication. Similarly, it allows RTP media streams in both directions. However, it may block, in either inbound or outbound direction, other protocols such as RSVP or it may disallow non-zero DSCPs. There are many degrees of SIP/RTP transparency, e.g., depending on whether firewalls require inspection of SDP content, thus precluding end-to- end encryption of certain SIP message bodies, or whether only outbound calls are allowed. Many corporate networks and semi-public access networks such as in hotels are likely to fall into this category. Restricted SIP networks: In restricted SIP networks, users may be restricted to particular SIP applications and cannot add SIP protocol elements such as header fields or use SIP methods beyond a proscribed set. It appears likely that 3GPP/3GPP2 networks will fall into this category, at least initially. It appears desirable that ETS users can employ the broadest possible set of networks during an emergency. Thus, it appears preferable that mechanisms work at least in SIP/RTP transparent networks and are added explicitly to restricted SIP networks. H. Schulzrinne [Page 6] Internet Draft RP Requirements July 30, 2002 6 General Requirements In the PSTN and certain private networks, such as those run by military organizations, calls are marked in various ways to indicate priorities. Below are some requirements for such a mechanism: Not specific to one mechanism or country: The mechanism should not be specific to one country or particular priority mechanism. For example, there are currently at least four priority schemes in widespread use: Q.735, with five levels, the U.S. defense network and NATO with five levels, the United States GETS (Government Emergency Telecommunications Systems) scheme with implied higher priority and the British Government Telephone Preference Scheme (GTPS) system. Usage of existing namespaces: Since there are a number of existing resource priority schemes for both the PSTN and private networks, it is likely that converged or VoIP networks will inherit these naming schemes. No loss of information: For the CN-IP-CN case, there should be no loss of signaling information caused by transiting the IP network. Extensibility: New naming schemes may need to be defined as resource priority mechanism are applied in additional private networks, or if a VoIP-specific priority scheme is being defined. Separation of indication and policy: The indication should not describe a particular detailed treatment, as it is likely that this depends on the nature of the resource and local policy. Instead, it should invoke a particular named policy. As an example, instead of specifying that a certain SIP request should be granted queueing priority, not cause preemption, but be restricted to three-minute sessions, the requests invokes a certain named policy that may well have those properties. Request-neutral: The mechanism chosen should work for any SIP request, not just, say, INVITE. It is then a matter of policy as to whether marking a particular SIP request leads to differentiated treatment or whether a particular SIP request needs to request such treatment by non-SIP means. H. Schulzrinne [Page 7] Internet Draft RP Requirements July 30, 2002 Default behavior: Network terminals configured to use priority scheme may occasionally end up making calls in a network that does not support such a scheme or the terminal may have an older list of priorities in a namespace. In those cases, the protocol must support a sensible default behavior that maximizes the chance for call completion without compromising network integrity. Address-neutral: The mechanism cannot rely on identifying a set of destination addresses or URI schemes. For example, in GETS-like schemes, the caller can reach any PSTN destination with increased probability of call completion, not just a limited set. Identity-independent: The user identity is insufficient to identify the priority level of the request. The same identity can issue non-prioritized requests as well as prioritized ones, with the range of priorities determined by the job function of the caller. The choice of the priority is made based on human judgement, following a set of general rules that are likely to be applied by analogy rather than precise mapping of each condition. For example, a particular circumstance may be considered similarly grave compared to one which is listed explicitly. Independent of network location: While some existing schemes restrict the set of priorities based on the line identity, it is recognized that future schemes should be flexible enough to avoid such reliance. Instead, a combination of authenticated user identity, user choice and policy determines the request treatment. Multiple simultaneous schemes: Some user agents will need to support multiple different priority schemes, as several will remain in use in networks run by different agencies and operators. (Not all user agents will have the means of authorizing callers using different schemes, and thus may be configured at run-time to only recognize certain namespaces.) Discovery: A terminal should be able to discover which priority name spaces are supported by a network element. Discovery may be explicit, where a user agent requests a list of the supported name spaces or it may be implicit, where it attempts to use a particular name space and is then told that this name space is not supported. Testing: It must be possible to test the system outside of H. Schulzrinne [Page 8] Internet Draft RP Requirements July 30, 2002 emergency conditions, to increase the chances that all elements work during an actual emergency. In particular, critical elements such as indication, authentication, authorization and call routing must be testable. 7 Policy and Mechanism Priority mechanisms can be roughly categorized by whether they use a priority queue for resource attempts or whether they preempt existing resource uses (e.g., calls). The choice between these mechanisms depends on the operational needs and characteristics of the network, e.g., on the number of active requests in the system and the fraction of prioritized calls. Generally, if the number of prioritized calls is small compared to the system capacity and the system capacity is large, it is likely that another call will naturally terminate in short order when a higher-priority call arrives. Thus, it is conceivable that the priority indication can cause preemption in some network entities, while elsewhere it just influences whether requests are queued instead of discarded and what queueing policy is being applied. Some namespaces may inherently imply a preemption policy, while others may be silent on whether preemption is to be used or not, leaving this to local entity policy. Similarly, the precise relationships between labels, e.g., what fraction of capacity is set aside for each priority level, is also a matter of local policy. This is similar to how differentiated services labels are handled. 8 Call Routing The routing of a SIP request, i.e., the proxies it visits and the UAs it ends up at, may depend on the fact that the SIP request is an ETS request. Compared to a non-ETS request for the same destination, the set of destinations may include UAs that are only supporting ETS service 9 Relationship to Emergency Call Services The resource priority mechanisms are used to have selected individuals place calls with elevated priority during times when the network is suffering from an emergency-induced shortage of resources. Generally, calls for emergency help placed by non-officials (e.g., "911" and "112" calls) do not need resource priority under normal circumstances. If such emergency calls are placed during emergency- induced network resource shortages, the call identifier itself is sufficient to identify the emergency nature of the call. Adding an H. Schulzrinne [Page 9] Internet Draft RP Requirements July 30, 2002 indication of resource priority may be less appropriate, as this would require that all such calls carry this indicator. Also, it opens another attack mechanism, where non-emergency calls are marked as emergency calls. (If the entity can recognize the request URI as an emergency call, it would not need the resource priority mechanism.) 10 Security Requirements Any resource priority mechanism can be abused to obtain resources and thus deny service to other 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. Additional discussion can be found in [1]. 10.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. Any indication of the resource priority mechanism must be independent of the authentication mechanism, since end systems will impose different constraints on the applicable authentication mechanisms. For example, some end systems may only allow user input via a 12- digit keypad, while others may have the ability to acquire biometrics or read smartcards. Since ETS users may use devices that are not their own, systems should support authentication mechanisms that do not require the user to reveal her secret to the device. Attackers may attempt to subvert the ETS infrastructure by overloading it with authentication attempts. Thus, mechanisms to delegate authentication and to authenticate as early as possible are required. In particular, the number of packets and the amount of other resources such as computation or storage that an unauthorized user can consume needs to be minimized. In general, unauthorized users must not be able to block CN resources, as they are likely to H. Schulzrinne [Page 10] Internet Draft RP Requirements July 30, 2002 be more scarce than packet resources. This implies that authentication and authorization must take place on the IP network side rather than using, say, a CN circuit to authenticate oneself via a DTMF sequence. 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. 10.2 Confidentiality and Integrity All aspects of ETS are likely to be sensitive and must 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, Subject and Via header fields are examples of particularly sensitive information. 10.3 Anonymity At least for existing ETS, support for anonymous calls are neither required nor desirable. 10.4 Denial-of-Service Attacks As noted, ETS systems are likely to be subject to deliberate denial- of-service 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. 11 Acknowledgements Fred Baker, Scott Bradner, Ken Carlberg, Rohan Mahy and James Polk provided helpful comments. 12 Bibliography [1] I. Brown, "A security framework for emergency communications," Internet Draft, Internet Engineering Task Force, June 2002. Work in progress. H. Schulzrinne [Page 11] Internet Draft RP Requirements July 30, 2002 13 Authors' Address Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA electronic mail: schulzrinne@cs.columbia.edu H. Schulzrinne [Page 12]