RFC3487 日本語訳
3487 Requirements for Resource Priority Mechanisms for the SessionInitiation Protocol (SIP). H. Schulzrinne. February 2003. (Format: TXT=39615 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Schulzrinne Request for Comments: 3487 Columbia University Category: Informational February 2003
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)
Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)
Status of this Memo
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.
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 Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
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).
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
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
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
Schulzrinne Informational [Page 1] RFC 3487 IEPREP SIP Requirements February 2003
1. Introduction
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.
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.
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.
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".
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.
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
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
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.
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.
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.
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.
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.
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.
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
2. Terminology
CSN: Circuit-switched network, encompassing both private (closed) networks and the public switched telephone network (PSTN).
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.
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.
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
Schulzrinne Informational [Page 3] RFC 3487 IEPREP SIP Requirements February 2003
3. Resources
3. Resources
Prioritized access to at least five resource types may be useful:
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.
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.
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.
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.
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.
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.
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.)
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
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.
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.
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.
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.
There is no requirement that a single mechanism be used for all five resources.
4. Network Topologies
4. Network Topologies
We consider four types of combinations of IP and circuit-switched networks.
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 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.
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
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-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.
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.
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.
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.
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)
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
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.
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.
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.
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
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.
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.
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.
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.
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.
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
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
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
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.)
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
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.
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
8. Policy and Mechanism
Most priority mechanisms can be roughly categorized by whether they:
Most priority mechanisms can be roughly categorized by whether they:
o use a priority queue for resource attempts,
o use a priority queue for resource attempts,
o make additional resources available (e.g., via alternate routing (ACR)), or
o make additional resources available (e.g., via alternate routing (ACR)), or
o preempt existing resource users (e.g., calls.)
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.
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.
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.
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.
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
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.
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
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".
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".
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.
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.
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.
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.
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-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.
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
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.
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-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.
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.
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-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.
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.
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-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
REQ-9: デフォルトの振舞い: 優先権体系を使用するために構成されたネットワーク端末は結局、そのような体系をサポートしないネットワークで電話を時折かけるかもしれません。 それらの場合では、プロトコルは優先権体系を呼び出さなかった呼び出しほど悪くない呼び出しを扱われる実際的なデフォルト値の振舞いにサポートしなければなりません。 ネットワークの中にはaを適当にしないなら呼び出しを禁じるのを選ぶものもあるかもしれません。
Schulzrinne Informational [Page 10] RFC 3487 IEPREP SIP Requirements February 2003
Schulzrinneの情報[10ページ]のRFC3487IEPREPは要件2003年2月にちびちび飲みます。
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.)
REQ-10: アドレス中立: どんなアドレスやURI体系も、有効な目的地であるかもしれなく、優先権体系で使用可能であるに違いありません。 SIP指示は特別な処理の1セットの送付先アドレスを特定するか、URI体系を当てにすることができません。 この要件は既存のETSシステムによって動機づけられています。例えば、GETSと同様のシステムでは、訪問者は限られたセットだけではなく、呼び出し完成の増強された確率でどんなPSTNの目的地にも着くことができます。 (これはそれが許容するか、または禁じるローカルの方針、たとえば呼び出しを確信しているユーザの国際的な数に排除しません。)
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.
いくつかの体系には、1つのオープン・セットの目的地があるかもしれません、どんな有効なE.164番号やどんな有効な国内の電話番号のようにも、他のものは限られたセットの目的地に着くだけであるかもしれませんが。
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-11: アイデンティティ独立者: SIPのFromヘッダーフィールドなどのように、ユーザアイデンティティは、要求の優先順位を特定するためには不十分です。 同じアイデンティティは最優先するものと同様に非最優先している要求を出すことができます、訪問者の職務権限で決定しているプライオリティの範囲で。 人間の判断に基づいて優先権の選択をします、1セットのそれぞれの状態の正確なマッピングよりむしろ類推で適用されそうな総則に従って。 例えば、明らかに記載されているものと比べて、特定の状況は荘重であると同様に考えられるかもしれません。
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-12: ネットワークの位置の無党派: いくつかの既存のCSN体系が系列のアイデンティティに基づくプライオリティのセットを制限している間、将来のIPベースの体系がそのような信用を避けるほどフレキシブルであるべきであると認められます。 代わりに、認証されたユーザのアイデンティティ、ユーザ選択、および方針の組み合わせは要求処理を決定します。
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-13: 複数の同時の体系: 何人かのユーザエージェントが、複数の異なった優先権が体系であるとサポートする必要があって、数個が残りのようになるように異なった政府機関とオペレータによって経営されていたネットワークで使用のままで残ってください。 (すべてのユーザエージェントが、異なった体系を使用することで訪問者に権限を与える手段を持って、その結果、ランタイムのときにある名前空間を認識するだけであるために構成されるかもしれないというわけではありません。)
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
REQ-14: 発見: 優先権名前空間がネットワーク要素によっていくらかサポートされるなら、端末はどれを発見するはずであることができるか。 発見は明白であるかもしれません、ユーザエージェントが、次に、この名前空間がサポートされないと言われた状態でサポートしている名前空間かそれのリストがそれが特定の名前空間を使用するのを試みて、あるところで暗に示されているかもしれないよう要求するところで。 これは、あらゆる要素がそうしなければならないのを含意しません。
Schulzrinne Informational [Page 11] RFC 3487 IEPREP SIP Requirements February 2003
Schulzrinneの情報[11ページ]のRFC3487IEPREPは要件2003年2月にちびちび飲みます。
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-15: テストします: 非常時の状態の外でシステムを検査するのは、すべての要素が実際の非常時に働いているという可能性を増強するために可能でなければなりません。 指示や、認証や、承認や呼び出しルーティングなどの重要な要素は特に、試験できなければなりません。 負荷の下でテストするのは望ましいです。 したがって、SIP指示が非常時だけでないのに絶え間なく利用可能であることは、望ましいです。
REQ-16: 3PCC: The system has to work with SIP third-party call control.
REQ-16: 3PCC: システムはSIP第三者呼び出しコントロールで動作しなければなりません。
REQ-17: Proxy-visible: Proxies may want to use the indication to influence request routing (see Section 7) or impose additional authentication requirements.
REQ-17: 目に見えるプロキシ: プロキシは、要求ルーティング(セクション7を見る)に影響を及ぼすか、または追加認証要件を課すのに指示を使用したがっているかもしれません。
10. Security Requirements
10. セキュリティ要件
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].
リソースを得て、その結果、他のユーザに対するサービスを否定するためにどんなリソース優先権メカニズムも誤用できます。 指示自体は別々の認証を提供する必要はありませんが、どんなSIPも、そのような情報を運ぶのにおいて定期的な要求より厳しい認証要件があるよう要求します。 以下では、私たちがサービス不能攻撃と匿名要件に対して認証と承認局面と秘密性とプライバシー要件、保護を説明します。 [6]で追加議論を見つけることができます。
10.1 Authentication and Authorization
10.1 認証と承認
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.
SEC-1: より厳しい: 最優先するリソースへのアクセスがたとえば、ただ一つの電話の窃盗で結果だけではなく、総合体系の安定性と性能に影響を与えるかもしれないので、セクション3で数え上げられたネットワークとエンドシステム資源への最優先するアクセスは特に厳しい要件を認証と承認メカニズムに課します。
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.
ETS呼び出しのための認証と承認要件は緊急通報(112、911)よりはるかに必要なら、広いアクセスが設計目標であるところで訪問者識別を犠牲にするのに特に強いです。
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.
SEC-2: 保護を攻撃してください: ある非常時の条件のもとでは、その認証と承認メカニズムを含むネットワークインフラは攻撃されているかもしれません。 したがって、認証と承認は、そのような攻撃を乗り切っていて、これらの攻撃に対してリソースを防御できなければなりません。
Schulzrinne Informational [Page 12] RFC 3487 IEPREP SIP Requirements February 2003
Schulzrinneの情報[12ページ]のRFC3487IEPREPは要件2003年2月にちびちび飲みます。
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.
権限のないユーザはCSNリソースを妨げることができるはずがありません、それらがパケットリソースより少ない傾向があるときに。 これは、認証と承認必須がDTMF系列で訪問者を認証するのにたとえばCSN回路を使用するよりIPネットワーク側でむしろ行われるのを含意します。
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.
SIPノードは、独自に最優先するサービスを受けるという要求の承認について確かめて、ネットワークの中で遷移的な信頼を当てにするはずであることができません。
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-3: メカニズムの無党派: リソース優先権のどんなしるしも認証機構から独立しているに違いありません、エンドシステムが異なった規制を適切な認証機構に課すので。例えば、いくつかのエンドシステムが12ケタのキーパッドを通してユーザ入力を許すだけであるかもしれません、他のものには、生体認証を習得するか、またはスマートカードを読む能力があるかもしれませんが。
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-4: 非信じられたエンドシステム: ETSユーザがそれら自身のでないデバイスを使用するかもしれないので、システムは、認証がユーザが秘密を打ち明けるのを必要としないメカニズムであるとサポートするはずです、暗証番号やパスワードのように、デバイスに。
SEC-5: Replay: The authentication mechanisms must be resistant to replay attacks.
SEC-5: 以下を再演してください。 認証機構は反射攻撃に抵抗力があるに違いありません。
SEC-6: Cut-and-paste: The authentication mechanisms must be resistant to cut-and-paste attacks.
SEC-6: カットアンドペースト: 認証機構はカットアンドペースト攻撃に抵抗力があるに違いありません。
SEC-7: Bid-down: The authentication mechanisms must be resistant to bid down attacks.
SEC-7: 下に付け値: 認証機構は、攻撃の下側に入札するために抵抗力がなければなりません。
10.2 Confidentiality and Integrity
10.2 秘密性と保全
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,
SEC-8: 秘密性: ETSの全面は、敏感であることがありそうであり、不法なインタセプトと変更から保護されるべきです。 コミュニケーション関係の秘密性を保護するための要件は通常の商業サービスより特に、高いかもしれません。 一口のために
Schulzrinne Informational [Page 13] RFC 3487 IEPREP SIP Requirements February 2003
Schulzrinneの情報[13ページ]のRFC3487IEPREPは要件2003年2月にちびちび飲みます。
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.
組織、Subject、Priority、およびViaヘッダーフィールドは特に機密の情報に関する例です。 唯一の選択肢が呼び出し試みを捨てることであるなら、訪問者は、秘密性を犠牲にしても構わないと思っているかもしれません。
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.
権限のないユーザは、特定の要求がリソース優先権メカニズムを使用しているのを裁量できるはずがありません、それが要求の本質に関する機密情報を攻撃者に明らかにするとき。 要求ルーティングに必要でない情報は、保護された中間的SIPノードからの終わりから終わりであるべきです。
The act of authentication, e.g., by contacting a particular server, itself may reveal that a user is requesting prioritized service.
サービスを最優先させましたそのaユーザが、要求している認証の行為、例えば、連絡するのによる特定のサーバ自体が、明らかにするかもしれない。
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.
SIPは要求ルーティングにS/MIMEで使用されないヘッダーフィールドの保護を許します、TLSかIPsecがホップごとのチャンネル秘密性を提供できますが。
10.3 Anonymity
10.3 匿名
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.
SEC-9: 匿名: 要求の目的地に匿名を希望するユーザもいるかもしれません。 より早く注意された理由で、ユーザは要求を運ぶネットワークに向かって自分たちを認証しなければなりません。 認証は必ず彼らの民間名前ではなく、能力とnomsに基づくかもしれません。
Clearly, they may remain anonymous towards the request destination, using the network-asserted identity and general privacy mechanisms [7,8].
明確に、ネットワークによって断言されたアイデンティティと一般的なプライバシーメカニズム[7、8]を使用して、彼らは要求の目的地に向かって匿名のままで残るかもしれません。
10.4 Denial-of-Service Attacks
10.4 サービス不能攻撃
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-10: サービスの否定: ETSシステムはあるタイプの非常時にサービス不能攻撃を熟考するためになることがある傾向があります。 DOS攻撃はその認証と承認メカニズムと同様にネットワーク自体で着手されるかもしれません。
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-11: 権限のないユーザによるリソース使用を最小にしてください: システムは権限のないユーザが命令することができる状態、計算、およびネットワーク資源の量を最小にするはずです。
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.
SEC-12: 増幅を避けてください: システムは、1つ以上のパケットかSIP要求の伝達を可到達性が確かめられていないネットワーク・アドレスに引き起こすことによって、攻撃を増幅してはいけません。
Schulzrinne Informational [Page 14] RFC 3487 IEPREP SIP Requirements February 2003
Schulzrinneの情報[14ページ]のRFC3487IEPREPは要件2003年2月にちびちび飲みます。
11. Security Considerations
11. セキュリティ問題
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.
セクション10は、SIPのために詳細に優先権指示に関連する安全保障問題について論じて、SIPインディケータのために要件を引き出します。 セクション6で議論するように、優先サービスの識別は攻撃者が無節操なラベリングを利用するのを許容するのを避けるために複数の同時発生のメカニズムを避けるべきです。
12. Acknowledgements
12. 承認
Ran Atkinson, Fred Baker, Scott Bradner, Ian Brown, Ken Carlberg, Janet Gunn, Kimberly King, Rohan Mahy and James Polk provided helpful comments.
役に立つコメントであるならアトキンソン、フレッド・ベイカー、スコット・ブラドナー、イアン・ブラウン、ケンCarlberg、ジャネット・ガン、キンバリー・キング、Rohanマーイ、およびジェイムズ・ポークを車で送りました。
13. Normative References
13. 引用規格
[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.
[1] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
14. Informative References
14. 有益な参照
[2] Lennox, J., Schulzrinne, H. and J. Rosenberg, "Common Gateway Interface for SIP", RFC 3050, January 2001.
[2] レノックスとJ.とSchulzrinneとH.とJ.ローゼンバーグ、「一口のための共通ゲートウェイインターフェイス」、RFC3050、2001年1月。
[3] Lennox J. and H. Schulzrinne, "CPL: A language for user control of internet telephony services", Work in Progress.
[3] レノックスJ.とH.Schulzrinne、「CPL:」 「インターネット電話サービスのユーザコントロールのための言語」、ProgressのWork。
[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.
[4]ZimmererとE.とピーターソンとJ.とVemuriとA.、オングとL.とAudetとF.とワトソンとM.とM.Zonoun、「ISUPとQSIGオブジェクトのためのMIMEメディアタイプ」RFC3204(2001年12月)。
[5] Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): (SIP-T)", BCP 63, RFC 3372, September 2002.
[5] Vemuri、A.、およびJ.ピーターソン、「セッション開始は電話(一口T)のために議定書を作ります」。 (一口T)「BCP63、RFC3372、2002年9月」
[6] Brown, I., "A security framework for emergency communications", Work in Progress.
[6] ブラウン、I.、「非常時のコミュニケーションのためのセキュリティフレームワーク」、ProgressのWork。
[7] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[7] ピーターソン、J.、「セッション開始プロトコル(一口)のためのプライバシーメカニズム」、RFC3323、2002年11月。
[8] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
[8] ワトソン、M.、「ネットワークの断言されたアイデンティティのための短期間要件」、RFC3324、2002年11月。
Schulzrinne Informational [Page 15] RFC 3487 IEPREP SIP Requirements February 2003
Schulzrinneの情報[15ページ]のRFC3487IEPREPは要件2003年2月にちびちび飲みます。
15. Author's Address
15. 作者のアドレス
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA
コンピュータサイエンスコロンビア大学1214アムステルダムAvenueニューヨーク10027ニューヨーク(米国)のヘニングSchulzrinne部
EMail: schulzrinne@cs.columbia.edu
メール: schulzrinne@cs.columbia.edu
Schulzrinne Informational [Page 16] RFC 3487 IEPREP SIP Requirements February 2003
Schulzrinneの情報[16ページ]のRFC3487IEPREPは要件2003年2月にちびちび飲みます。
16. Full Copyright Statement
16. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Schulzrinne Informational [Page 17]
Schulzrinne情報です。[17ページ]
一覧
スポンサーリンク