diff options
Diffstat (limited to 'doc/rfc/rfc3487.txt')
| -rw-r--r-- | doc/rfc/rfc3487.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc3487.txt b/doc/rfc/rfc3487.txt new file mode 100644 index 0000000..3966de4 --- /dev/null +++ b/doc/rfc/rfc3487.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group H. Schulzrinne +Request for Comments: 3487 Columbia University +Category: Informational February 2003 + + + Requirements for Resource Priority Mechanisms for the + Session Initiation Protocol (SIP) + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document summarizes requirements for prioritizing access to + circuit-switched network, end system and proxy resources for + emergency preparedness communications using the Session Initiation + Protocol (SIP). + +Table of Contents + + 1. Introduction ................................................ 2 + 2. Terminology ................................................. 3 + 3. Resources ................................................... 4 + 4. Network Topologies .......................................... 5 + 5. Network Models .............................................. 6 + 6. Relationship to Emergency Call Services ..................... 7 + 7. SIP Call Routing ............................................ 8 + 8. Policy and Mechanism ........................................ 8 + 9. Requirements ................................................ 9 + 10. Security Requirements ....................................... 12 + 10.1 Authentication and Authorization ....................... 12 + 10.2 Confidentiality and Integrity .......................... 13 + 10.3 Anonymity .............................................. 14 + 10.4 Denial-of-Service Attacks .............................. 14 + 11. Security Considerations ..................................... 15 + 12. Acknowledgements ............................................ 15 + 13. Normative References ........................................ 15 + 14. Informative References ...................................... 15 + 15. Author's Address ............................................ 16 + 16. Full Copyright Statement .................................... 17 + + + + +Schulzrinne Informational [Page 1] + +RFC 3487 IEPREP SIP Requirements February 2003 + + +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. + + There are many IP-based services that can assist during emergencies. + This memo only covers requirements for real-time communications + applications involving the Session Initiation Protocol (SIP) [1], + including voice-over-IP, multimedia conferencing and instant + messaging/presence. + + 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 Session Initiation Protocol + (SIP) [1] 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 protocol features. 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. + 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 + + + + + +Schulzrinne Informational [Page 2] + +RFC 3487 IEPREP SIP Requirements February 2003 + + + the IP network, Section 5 attempts to classify networks into + categories according to the restrictions placed on modifications and + traffic classes. + + Since this is a major source of confusion due to similar names, + Section 6 attempts to distinguish emergency call services placed by + civilians from the topic of this document. + + Request routing is a core component of SIP, covered in Section 7. + + Providing resource priority entails complex implementation choices, + so that a single priority scheme leads to a set of algorithms that + manage queues, resource consumption and resource usage of existing + calls. Even 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 8 discusses + the call-by-value (specification of mechanisms) and call-by-reference + (invoke labeled policy) distinction. + + Based on these discussions, Section 9 summarizes some general + requirements that try to achieve generality and feature-transparency + across hybrid networks. + + The most challenging component of resource prioritization 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 + + CSN: Circuit-switched network, encompassing both private + (closed) networks and the public switched telephone network + (PSTN). + + 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 CSN 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. + + + + + +Schulzrinne Informational [Page 3] + +RFC 3487 IEPREP SIP Requirements February 2003 + + +3. Resources + + Prioritized access to at least five resource types may be useful: + + Gateway resources: The number of channels (trunks) on a CSN + gateway is finite. Resource prioritization may prioritize access + to these channels, by priority queuing or preemption. + + CSN resources: Resources in the CSN itself, away from the access + gateway, may be congested. This is the domain of traditional + resource prioritization mechanisms such as MLPP and GETS, where + circuits are granted to ETS communications based on queuing + priority or preemption (if allowed by local telecommunication + regulatory policy and local administrative procedures). A gateway + may also use alternate routing (Section 8) to increase the + probability of call completion. + + Specifying CSN 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, emergency services applications may not be + able to obtain sufficient bandwidth in any network. When there + are insufficient network resources for all users and it is not + practical to simply add more resources, quality of service + management is necessary to solve this problem. This is orthogonal + to SIP, out of the scope for SIP, and as such these requirements + will be discussed in another document. + + Bandwidth used for SIP signaling itself may be subject to + prioritization. + + Receiving end system resources: End systems may include + automatic call distribution systems (ACDs) or media servers as + well as traditional telephone-like devices. Gateways are also end + systems, but have been discussed earlier. + + Since 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.) + + + + + + +Schulzrinne Informational [Page 4] + +RFC 3487 IEPREP SIP Requirements February 2003 + + + Such terminating services may be needed to avoid overloading, say, + an emergency coordination center. However, other approaches 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 approaches 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, sip-cgi [2] and CPL [3] scripts, etc. Thus, avoiding + proxy overload by restricting access bandwidth is likely to lead + to inefficient utilization of the proxy.) Therefore, some types + of proxies may need to silently drop selected SIP requests under + overload, reject requests, with overload indication or provide + multiple queues with different drop and scheduling priorities for + different types of SIP requests. However, this is strictly an + implementation issue and does not appear to influence the protocol + requirements nor the on-the-wire protocol. Thus, it is out of + scope for the protocol requirements discussion pursued here. + + Responses should naturally receive the same treatment as the + corresponding request. Responses already have to be securely + mapped to requests, so this requirement does not pose a + significant burden. Since proxies often do not maintain call + state, it is not generally feasible to assign elevated priority to + requests originating from a lower-privileged callee back to the + higher-privileged caller. + + There is no requirement that a single mechanism be used for all five + resources. + +4. Network Topologies + + We consider four types of combinations of IP and circuit-switched + networks. + + IP end-to-end: Both request originator and destination are on an + IP network, without intervening CSN-IP gateways. Here, any SIP + request could be subject to prioritization. + + IP-to-CSN (IP at the start): The request originator is in the IP + network, while the callee is in the CSN. Clearly, this model only + applies to SIP-originated phone calls, not generic SIP requests + such as those supporting instant messaging services. + + + + +Schulzrinne Informational [Page 5] + +RFC 3487 IEPREP SIP Requirements February 2003 + + + CSN-to-IP (IP at the end): A call originates in the CSN and + terminates, via an Internet telephony gateway, in the IP network. + + CSN-IP-CSN (IP bridging): This is a concatenation of the two + previous ones. It is worth calling out specifically to note that + the two CSN sides may use different signaling protocols. Also, + the originating CSN endpoint and the gateway to the IP network may + not know the nature of the terminating CSN. Thus, encapsulation + of originating CSN information is insufficient. + + The bridging model (IP-CSN-IP) can be treated as the concatenation of + the IP-to-CSN and CSN-to-IP cases. + + It is worth emphasizing that CSN-to-IP gateways are unlikely to know + whether the final destination is in the IP network, the CSN or, via + SIP forking, in both. + + These models differ in the type of controllable resources, identified + as gateway, CSN, IP network resources, proxy and receiver. Items + marked as (x) are beyond the scope of this document. + + Topology Gateway CSN IP proxy receiver + _________________________________________________ + IP-end-to-end (x) (x) x + IP-to-CSN x x (x) (x) (x) + CSN-to-IP x x (x) (x) x + CSN-IP-CSN x x (x) (x) (x) + +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. + + Pre-configured for ETS: In a pre-configured 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, 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. + + + +Schulzrinne Informational [Page 6] + +RFC 3487 IEPREP SIP Requirements February 2003 + + + SIP/RTP transparent: Networks that are SIP/RTP transparent 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 + firewalled 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 prescribed set. It appears likely that 3GPP/3GPP2 networks will + fall into this category, at least initially. + + A separate and distinct problem are SIP networks that + administratively prohibit or fail to configure access to special + access numbers, e.g., the 710 area code used by GETS. Such + operational failures are beyond the reach of a protocol + specification. + + It appears desirable that ETS users can employ the broadest possible + set of networks during an emergency. Thus, it appears preferable + that protocol enhancements work at least in SIP/RTP transparent + networks and are added explicitly to restricted SIP networks. + + The existing GETS system relies on a transparent network, allowing + use from most unmodified telephones, while MLPP systems are typically + pre-configured. + +6. 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 a 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 indication of + resource priority may be less appropriate, as this would require that + all such calls carry this indicator. Also, it opens another attack + + + + + +Schulzrinne Informational [Page 7] + +RFC 3487 IEPREP SIP Requirements February 2003 + + + mechanism, where non-emergency calls are marked as emergency calls. + (If network elements can recognize the request URI as an emergency + call, they would not need the resource priority mechanism.) + +7. SIP 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. The set of destinations may be larger or smaller, depending + on the SIP request routing policies implemented by proxies. For + example, certain gateways may be reserved for ETS use and thus only + be reached by labeled SIP requests. + +8. Policy and Mechanism + + Most priority mechanisms can be roughly categorized by whether they: + + o use a priority queue for resource attempts, + + o make additional resources available (e.g., via alternate routing + (ACR)), or + + o preempt existing resource users (e.g., calls.) + + For example, in GETS, alternate routing attempts to use alternate + GETS-enabled interexchange carriers (IXC) if it cannot be completed + through the first-choice carrier. + + Priority mechanisms may also exempt certain calls from network + management traffic controls. + + 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. + + + + + + +Schulzrinne Informational [Page 8] + +RFC 3487 IEPREP SIP Requirements February 2003 + + + 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. + +9. Requirements + + In the PSTN and certain private circuit-switched networks, such as + those run by military organizations, calls are marked in various ways + to indicate priorities. We call this a "priority scheme". + + Below are some requirements for providing a similar feature in a SIP + environment; security requirements are discussed in Section 10. We + will refer to the feature as a "SIP indication" and to requests + carrying such an indication as "labelled requests". + + Note: Not all the following requirements are possible to meet at + once. They may represent in some case tradeoffs that must be + considered by the designer. + + REQ-1: Not specific to one scheme or country: The SIP indication + should support existing and future priority schemes. For example, + there are currently at least four priority schemes in widespread + use: Q.735, also implemented by the U.S. defense telephone + network ("DSN" or "Autovon") and NATO, has five levels, the United + States GETS (Government Emergency Telecommunications Systems) + scheme with implied higher priority and the British Government + Telephone Preference Scheme (GTPS) system, which provides three + priority levels for receipt of dial tone. + + The SIP indication may support these existing CSN priority schemes + through the use of different namespaces. + + Private-use namespaces may also be useful for certain + applications. + + REQ-2: Independent of particular network architecture: The SIP + indication should work in the widest variety of SIP-based systems. + It should not be restricted to particular operators or types of + networks, such as wireless networks or protocol profiles and + dialects in certain types of networks. The originator of a SIP + request cannot be expected to know what kind of circuit-switched + technology is used by the destination gateway. + + REQ-3: Invisible to network (IP) layer: The SIP indication must + be usable in IP networks that are unaware of the enhancement and + in SIP/RTP-transparent networks. + + + + +Schulzrinne Informational [Page 9] + +RFC 3487 IEPREP SIP Requirements February 2003 + + + This requirement can be translated to mean that the request has to + be a valid SIP request and that out-of-band signaling is not + acceptable. + + REQ-4: Mapping of existing schemes: Existing CSN schemes must be + translatable to SIP-based systems. + + REQ-5: No loss of information: For the CSN-IP-CSN case, there + should be no loss of signaling information caused by translation + from CSN signaling SIP and back from SIP to CSN signaling if both + circuit-switched networks use the same priority scheme. Loss of + information may be unavoidable if the destination CSN uses a + different priority scheme from the origin. + + One cannot assume that both CSNs are using the same signaling + protocol or protocol version, such as ISUP, so that transporting + ISUP objects in MIME [4,5] is unlikely to be sufficient. + + REQ-6: Extensibility: Any naming scheme specified as part of the + SIP indication should allow for future expansion. Expanded naming + schemes may be needed as resource priority is applied in + additional private networks, or if VoIP-specific priority schemes + are defined. + + REQ-7: Separation of policy and mechanism: The SIP 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 request invokes a certain + named policy that may well have those properties in a particular + implementation. An IP-to-CSN gateway may need to be aware of the + specific actions required for the policy, but the protocol + indication itself should not. + + Even in the CSN, the same MLPP indication may result in different + behavior for different networks. + + REQ-8: Method-neutral: The SIP indication chosen should work for + any SIP method, not just, say, INVITE. + + REQ-9: Default behavior: Network terminals configured to use a + priority scheme may occasionally end up making calls in a network + that does not support such a scheme. In those cases, the protocol + must support a sensible default behavior that treats the call no + worse than a call that did not invoke the priority scheme. Some + networks may choose to disallow calls unless they have a suitable + + + +Schulzrinne Informational [Page 10] + +RFC 3487 IEPREP SIP Requirements February 2003 + + + priority marking and appropriate authentication. This is a matter + of local policy. + + REQ-10: Address-neutral: Any address or URI scheme may be a + valid destination and must be usable with the priority scheme. + The SIP indication cannot rely on identifying a set of destination + addresses or URI schemes for special treatment. This requirement + is motivated by existing ETS systems. For example, in GETS and + similar systems, the caller can reach any PSTN destination with + increased probability of call completion, not just a limited set. + (This does not preclude local policy that allows or disallows, + say, calls to international numbers for certain users.) + + Some schemes may have an open set of destinations, such as any + valid E.164 number or any valid domestic telephone number, while + others may only reach a limited set of destinations. + + REQ-11: Identity-independent: The user identity, such as the + From header field in SIP, 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. + + REQ-12: Independent of network location: While some existing CSN + schemes restrict the set of priorities based on the line identity, + it is recognized that future IP-based schemes should be flexible + enough to avoid such reliance. Instead, a combination of + authenticated user identity, user choice and policy determines the + request treatment. + + REQ-13: 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.) + + REQ-14: Discovery: A terminal should be able to discover which, + if any, priority namespaces are supported by a network element. + Discovery may be explicit, where a user agent requests a list of + the supported namespaces or it may be implicit, where it attempts + to use a particular namespace and is then told that this namespace + is not supported. This does not imply that every element has to + + + +Schulzrinne Informational [Page 11] + +RFC 3487 IEPREP SIP Requirements February 2003 + + + support the priority scheme. However, entities should be able + discover whether a network element supports it or not. + + REQ-15: Testing: It must be possible to test the system outside + of 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. Testing under load is desirable. Thus, it is + desirable that the SIP indication is available continuously, not + just during emergencies. + + REQ-16: 3PCC: The system has to work with SIP third-party call + control. + + REQ-17: Proxy-visible: Proxies may want to use the indication to + influence request routing (see Section 7) or impose additional + authentication requirements. + +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 more rigorous 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 [6]. + +10.1 Authentication and Authorization + + SEC-1: More rigorous: Prioritized access to network and end + system resources enumerated in Section 3 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. + + The authentication and authorization requirements for ETS calls + are, in particular, much stronger than for emergency calls (112, + 911), where wide access is the design objective, sacrificing + caller identification if necessary. + + SEC-2: Attack protection: Under certain emergency conditions, + the network infrastructure, including its authentication and + authorization mechanism, may be under attack. Thus, + authentication and authorization must be able to survive such + attacks and defend the resources against these attacks. + + + +Schulzrinne Informational [Page 12] + +RFC 3487 IEPREP SIP Requirements February 2003 + + + 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. + + Unauthorized users must not be able to block CSN resources, as + they are likely to 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 CSN circuit to + authenticate the caller 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. + + SIP nodes should be able to independently verify the authorization + of requests to receive prioritized service and not rely on + transitive trust within the network. + + SEC-3: Independent of mechanism: Any indication of the resource + priority 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. + + SEC-4: Non-trusted end systems: 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, such + as a PIN or password, to the device. + + SEC-5: Replay: The authentication mechanisms must be resistant + to replay attacks. + + SEC-6: Cut-and-paste: The authentication mechanisms must be + resistant to cut-and-paste attacks. + + SEC-7: Bid-down: The authentication mechanisms must be resistant + to bid down attacks. + +10.2 Confidentiality and Integrity + + SEC-8: Confidentiality: All aspects of ETS are likely to be + sensitive and should be protected from unlawful 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, + + + +Schulzrinne Informational [Page 13] + +RFC 3487 IEPREP SIP Requirements February 2003 + + + Organization, Subject, Priority and Via header fields are examples + of particularly sensitive information. Callers may be willing to + sacrifice confidentiality if the only alternative is abandoning + the call attempt. + + Unauthorized users must not be able to discern that a particular + request is using a resource priority mechanism, as that may reveal + sensitive information about the nature of the request to the + attacker. Information not required for request routing should be + protected end-to-end from intermediate SIP nodes. + + The act of authentication, e.g., by contacting a particular + server, itself may reveal that a user is requesting prioritized + service. + + SIP allows protection of header fields not used for request + routing via S/MIME, while hop-by-hop channel confidentiality can + be provided by TLS or IPsec. + +10.3 Anonymity + + SEC-9: Anonymity: Some users may wish to remain anonymous to the + request destination. For the reasons noted earlier, users have to + authenticate themselves towards the network carrying the request. + 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 mechanisms [7,8]. + +10.4 Denial-of-Service Attacks + + SEC-10: Denial-of-service: 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. + + SEC-11: Minimize resource use by unauthorized users: Systems + should minimize the amount of state, computation and + network resources that an unauthorized user can command. + + SEC-12: Avoid amplification: The system must not amplify attacks + by causing the transmission of more than one packet or SIP + request to a network address whose reachability has not + been verified. + + + + +Schulzrinne Informational [Page 14] + +RFC 3487 IEPREP SIP Requirements February 2003 + + +11. Security Considerations + + Section 10 discusses the security issues related to priority + indication for SIP in detail and derives requirements for the SIP + indicator. As discussed in Section 6, identification of priority + service should avoid multiple concurrent mechanisms, to avoid + allowing attackers to exploit inconsistent labeling. + +12. Acknowledgements + + Ran Atkinson, Fred Baker, Scott Bradner, Ian Brown, Ken Carlberg, + Janet Gunn, Kimberly King, Rohan Mahy and James Polk provided helpful + comments. + +13. Normative References + + [1] 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. + +14. Informative References + + [2] Lennox, J., Schulzrinne, H. and J. Rosenberg, "Common Gateway + Interface for SIP", RFC 3050, January 2001. + + [3] Lennox J. and H. Schulzrinne, "CPL: A language for user control + of internet telephony services", Work in Progress. + + [4] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., + Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG + objects", RFC 3204, December 2001. + + [5] Vemuri, A. and J. Peterson, "Session Initiation Protocol for + Telephones (SIP-T): (SIP-T)", BCP 63, RFC 3372, September 2002. + + [6] Brown, I., "A security framework for emergency communications", + Work in Progress. + + [7] Peterson, J., "A Privacy Mechanism for the Session Initiation + Protocol (SIP)", RFC 3323, November 2002. + + [8] Watson, M., "Short Term Requirements for Network Asserted + Identity", RFC 3324, November 2002. + + + + + + + + +Schulzrinne Informational [Page 15] + +RFC 3487 IEPREP SIP Requirements February 2003 + + +15. Author's Address + + Henning Schulzrinne + Dept. of Computer Science + Columbia University + 1214 Amsterdam Avenue + New York, NY 10027 + USA + + EMail: schulzrinne@cs.columbia.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schulzrinne Informational [Page 16] + +RFC 3487 IEPREP SIP Requirements February 2003 + + +16. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Schulzrinne Informational [Page 17] + |