< draft-ietf-ieprep-sip-reqs-01.txt   draft-ietf-ieprep-sip-reqs-02.txt >
Internet Engineering Task Force IEPREP Internet Engineering Task Force IEPREP
Internet Draft H. Schulzrinne Internet Draft H. Schulzrinne
Columbia U. Columbia U.
draft-ietf-ieprep-sip-reqs-01.txt draft-ietf-ieprep-sip-reqs-02.txt
October 21, 2002 December 2, 2002
Expires: March 2003 Expires: May 2003
Requirements for Resource Priority Mechanisms for the Session Requirements for Resource Priority Mechanisms for the Session
Initiation Protocol Initiation Protocol
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 2, line 13 skipping to change at page 2, line 13
assistance, recovery or law enforcement to coordinate their efforts. assistance, recovery or law enforcement to coordinate their efforts.
As IP networks become part of converged or hybrid networks along with As IP networks become part of converged or hybrid networks along with
public and private circuit-switched (telephone) networks, it becomes public and private circuit-switched (telephone) networks, it becomes
necessary to ensure that these networks can assist during such necessary to ensure that these networks can assist during such
emergencies. emergencies.
There are many IP-based services that can assist during emergencies. There are many IP-based services that can assist during emergencies.
This memo only covers requirements for real-time communications This memo only covers requirements for real-time communications
applications involving SIP, including voice-over-IP, multimedia applications involving SIP, including voice-over-IP, multimedia
conferencing and instant messaging/presence. Almost any other conferencing and instant messaging/presence.
communications application may be useful during emergency situations.
In general, these applications may benefit from network resource This document takes no position as to which mode of communication is
prioritization and thus some of the remarks and requirements may preferred during an emergency, as such discussion appears to be of
apply. However, detailed discussion and requirements are left to little practical value. Based on past experience, real-time
other documents. This document takes no position as to which mode of communications is likely to be an important component of any overall
communication is preferred during an emergency, as such discussion suite of applications, particularly for coordination of emergency-
appears to be of little practical value. Based on past experience, related efforts.
real-time communications is likely to be an important component of
any overall suite of applications, particularly for coordination of
emergency-related efforts.
As we will describe in detail below, such SIP applications involve at As we will describe in detail below, such SIP applications involve at
least five different resources that may become scarce and congested least five different resources that may become scarce and congested
during emergencies. In order to improve emergency response, it may during emergencies. In order to improve emergency response, it may
become necessary to prioritize access to such resources during become necessary to prioritize access to such resources during
periods of emergency-induced resource scarcity. We call this periods of emergency-induced resource scarcity. We call this
"resource prioritization". "resource prioritization".
This document describes requirements rather than possible existing or This document describes requirements rather than possible existing or
new protocol features. Although it is scoped to deal with SIP-based new protocol features. Although it is scoped to deal with SIP-based
applications, this should not be taken to imply that mechanisms have applications, this should not be taken to imply that mechanisms have
to be SIP protocol features such as header fields, methods or URI to be SIP protocol features such as header fields, methods or URI
parameters. parameters.
The document is organized as follows. In Section 2, we explain core The document is organized as follows. In Section 2, we explain core
technical terms and acronyms that are used throughout the document. technical terms and acronyms that are used throughout the document.
[Some of these may migrate to a terminology document.] Section 3 Section 3 describes the five types of resources that may be subject
describes the five types of resources that may be subject to resource to resource prioritization. Section 4 enumerates four network hybrids
prioritization. Section 4 enumerates four network hybrids that that determine which of these resources are relevant. Since the
determine which of these resources are relevant. Since the design design choices may be constrained by the assumptions placed on the IP
choices may be constrained by the assumptions placed on the IP
network, Section 5 attempts to classify networks into categories network, Section 5 attempts to classify networks into categories
according to the restrictions placed on modifications and traffic according to the restrictions placed on modifications and traffic
classes. Section 6 summarizes some general requirements that try to classes.
achieve generality and feature-transparency across hybrid networks.
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, Providing resource priority entails complex implementation choices,
so that a single priority scheme leads to a set of algorithms that so that a single priority scheme leads to a set of algorithms that
manage queues, resource consumption and resource usage of existing manage queues, resource consumption and resource usage of existing
calls. Even within a single administrative domain, the combination of calls. Even within a single administrative domain, the combination of
mechanisms is likely to vary. Since it will also depend on the mechanisms is likely to vary. Since it will also depend on the
interaction of different policies, it appears inappropriate to have interaction of different policies, it appears inappropriate to have
SIP applications specify the precise mechanisms. Section 7 discusses SIP applications specify the precise mechanisms. Section 8 discusses
the call-by-value (specification of mechanisms) and call-by-reference the call-by-value (specification of mechanisms) and call-by-reference
(invoke labeled policy) distinction. (invoke labeled policy) distinction.
Request routing is a core component of SIP, covered in Section 8. Based on these discussions, Section 9 summarizes some general
requirements that try to achieve generality and feature-transparency
Since this is a major source of confusion due to similar names, across hybrid networks.
Section 9 attempts to distinguish emergency call services placed by
civilians from the topic of this document.
The most challenging component of resource prioritization is likely The most challenging component of resource prioritization is likely
to be security (Section 10). Without adequate security mechanisms, to be security (Section 10). Without adequate security mechanisms,
resource priority may cause more harm than good, so that the section resource priority may cause more harm than good, so that the section
attempts to enumerate some of the specific threats present when attempts to enumerate some of the specific threats present when
resource prioritization is being employed. resource prioritization is being employed.
2 Terminology 2 Terminology
CSN: Circuit-switched network, encompassing both private CSN: Circuit-switched network, encompassing both private
skipping to change at page 4, line 8 skipping to change at page 4, line 7
gateway is finite. Resource prioritization may prioritize gateway is finite. Resource prioritization may prioritize
access to these channels, by priority queuing or access to these channels, by priority queuing or
preemption. preemption.
CSN resources: Resources in the CSN itself, away from the access CSN resources: Resources in the CSN itself, away from the access
gateway, may be congested. This is the domain of gateway, may be congested. This is the domain of
traditional resource prioritization as MLPP and GETS, where traditional resource prioritization as MLPP and GETS, where
circuits are granted to ETS communications based on circuits are granted to ETS communications based on
queueing priority or preemption (if allowed by local queueing priority or preemption (if allowed by local
telecommunication regulatory policy). A gateway may also telecommunication regulatory policy). A gateway may also
use alternate routing (Section 7) to increase the use alternate routing (Section 8) to increase the
probability of call completion. probability of call completion.
Specifying CSN behavior is beyond the scope of this Specifying CSN behavior is beyond the scope of this
document, but as noted below, a central requirement is to document, but as noted below, a central requirement is to
be able to invoke all such behaviors from an IP endpoint. be able to invoke all such behaviors from an IP endpoint.
IP network resources: SIP may initiate voice and multimedia IP network resources: SIP may initiate voice and multimedia
sessions. In many cases, audio and video streams are sessions. In many cases, audio and video streams are
inelastic and have tight delay and loss requirements. Under inelastic and have tight delay and loss requirements. Under
conditions of IP network overload, emergency services conditions of IP network overload, emergency services
skipping to change at page 5, line 20 skipping to change at page 5, line 19
requests under overload, reject requests, with overload requests under overload, reject requests, with overload
indication or provide multiple queues with different drop indication or provide multiple queues with different drop
and scheduling priorities for different types of SIP and scheduling priorities for different types of SIP
requests. However, this is strictly an implementation requests. However, this is strictly an implementation
isssue and does not appear to influence the protocol isssue and does not appear to influence the protocol
requirements nor the on-the-wire protocol. Thus, it is out requirements nor the on-the-wire protocol. Thus, it is out
of scope for the protocol requirements discussion pursued of scope for the protocol requirements discussion pursued
here. here.
Responses should naturally receive the same treatment Responses should naturally receive the same treatment
as responses. However, responses already have to be as the corresponding request. Responses already have
securely mapped to requests, so this does not add to be securely mapped to requests, so this requirement
significant overhead. Since proxies often do not does not pose a significant burden. Since proxies
maintain call state, it is not generally feasible to often do not maintain call state, it is not generally
assign elevated priority to requests originating from feasible to assign elevated priority to requests
a lower-privileged callee back to the higher- originating from a lower-privileged callee back to the
privileged caller. higher-privileged caller.
There is no requirement that a single mechanism be used for all five There is no requirement that a single mechanism be used for all five
resources. resources.
4 Hybrid Networks 4 Network Topologies
We consider four types of combinations of IP and circuit-switched We consider four types of combinations of IP and circuit-switched
networks. networks.
IP only: Both request originator and destination are on an IP IP end-to-end: Both request originator and destination are on an |
network, without intervening CSN-IP gateways. Here, any SIP IP network, without intervening CSN-IP gateways. Here, any |
request could be subject to prioritization. SIP request could be subject to prioritization. |
IP-to-CSN: The request originator is in the IP network, while IP-to-CSN (IP at the start): The request originator is in the IP |
the callee is in the CSN. Clearly, this model only applies network, while the callee is in the CSN. Clearly, this |
to SIP-originated phone calls, not generic SIP requests model only applies to SIP-originated phone calls, not |
such as those supporting instant messaging services. generic SIP requests such as those supporting instant |
messaging services. |
CSN-to-IP: A call originates in the CSN and terminates, via an CSN-to-IP (IP at the end): A call originates in the CSN and |
Internet telephony gateway, in the IP network. terminates, via an Internet telephony gateway, in the IP |
network. |
CSN-IP-CSN (SIP bridging): This is a concatenation of the two CSN-IP-CSN (IP bridging): This is a concatenation of the two |
previous ones. It is worth calling out specifically to note previous ones. It is worth calling out specifically to note |
that the two CSN sides may use different signaling that the two CSN sides may use different signaling |
protocols. Also, the originating CSN endpoint and the protocols. Also, the originating CSN endpoint and the |
gateway to the IP network may not know the nature of the gateway to the IP network may not know the nature of the |
terminating CSN. Thus, encapsulation of originating CSN terminating CSN. Thus, encapsulation of originating CSN |
information is insufficient. information is insufficient. |
The bridging model IP-CSN-IP can be treated as the concatenation of The bridging model (IP-CSN-IP) can be treated as the concatenation of
the IP-to-CSN and CSN-to-IP cases. the IP-to-CSN and CSN-to-IP cases.
It is worth emphasizing that CSN-to-IP gateways are unlikely to know 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 whether the final destination is in the IP network, the CSN or, via
SIP forking, in both. SIP forking, in both.
These models differ in the type of controllable resources, identified These models differ in the type of controllable resources, identified
as gateway, CSN, IP network resources, proxy and receiver. Items as gateway, CSN, IP network resources, proxy and receiver. Items
marked as (x) are beyond the scope of this document. marked as (x) are beyond the scope of this document.
Hybrid Gateway CSN IP proxy receiver Topology Gateway CSN IP proxy receiver
______________________________________________ _________________________________________________
IP-only (x) (x) x IP-end-to-end (x) (x) x
IP-to-CSN x x (x) (x) (x) IP-to-CSN x x (x) (x) (x)
CSN-to-IP x x (x) (x) x CSN-to-IP x x (x) (x) x
CSN-IP-CSN 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 There are at least four IP network models that influence the
requirements for resource priority. Each model inherits the requirements for resource priority. Each model inherits the
restrictions of the model above it. restrictions of the model above it.
Pre-configured for ETS: In a pre-configured network, an ETS Pre-configured for ETS: In a pre-configured network, an ETS
application can use any protocol carried in IP packets and application can use any protocol carried in IP packets and
modify the behavior of existing protocols. As an example, modify the behavior of existing protocols. As an example,
skipping to change at page 7, line 42 skipping to change at page 7, line 42
It appears desirable that ETS users can employ the broadest possible It appears desirable that ETS users can employ the broadest possible
set of networks during an emergency. Thus, it appears preferable that set of networks during an emergency. Thus, it appears preferable that
protocol enhancements work at least in SIP/RTP transparent networks protocol enhancements work at least in SIP/RTP transparent networks
and are added explicitly to restricted SIP networks. and are added explicitly to restricted SIP networks.
The existing GETS system is an example of an "opportunistic" network, The existing GETS system is an example of an "opportunistic" network,
allowing use from most unmodified telephones, while MLPP systems are allowing use from most unmodified telephones, while MLPP systems are
typically pre-configured. typically pre-configured.
6 Requirements 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
mechanism, where non-emergency calls are marked as emergency calls.
(If the entity can recognize the request URI as an emergency call, it
would not need the resource priority mechanism.)
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.
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 In the PSTN and certain private circuit-switched networks, such as
those run by military organizations, calls are marked in various ways those run by military organizations, calls are marked in various ways
to indicate priorities. We call this a "priority scheme". to indicate priorities. We call this a "priority scheme".
Below are some requirements for providing such a feature in a SIP Below are some requirements for providing a similar feature in a SIP
environment; security requirements are discussed in Section 10. We environment; security requirements are discussed in Section 10. We
will refer to the feature as a "SIP indication". will refer to the feature as a "SIP indication" and to requests
carrying such an indication as "labelled requests".
REQ-1: Not specific to one scheme or country: The SIP indication REQ-1: Not specific to one scheme or country: The SIP indication
should support existing and future priority schemes. For should support existing and future priority schemes. For
example, there are currently at least four priority schemes example, there are currently at least four priority schemes
in widespread use: Q.735, also implemented by the U.S. in widespread use: Q.735, also implemented by the U.S.
defense network and NATO, has five levels, the United defense network and NATO, has five levels, the United
States GETS (Government Emergency Telecommunications States GETS (Government Emergency Telecommunications
Systems) scheme with implied higher priority and the Systems) scheme with implied higher priority and the
British Government Telephone Preference Scheme (GTPS) British Government Telephone Preference Scheme (GTPS)
system, which provides three priority levels for receipt of system, which provides three priority levels for receipt of
skipping to change at page 8, line 37 skipping to change at page 10, line 5
networks. The originator of a SIP request cannot be networks. The originator of a SIP request cannot be
expected to know what kind of CS technology is used by the expected to know what kind of CS technology is used by the
destination gateway. destination gateway.
REQ-3: Invisible to network (IP) layer: The SIP indication must REQ-3: Invisible to network (IP) layer: The SIP indication must
be usable in IP networks that are unaware of the be usable in IP networks that are unaware of the
enhancement and in SIP/RTP-transparent networks. Obviously, enhancement and in SIP/RTP-transparent networks. Obviously,
such networks will not be able to provide enhanced such networks will not be able to provide enhanced
services. services.
This requirement can be translated to mean that the request | This requirement can be translated to mean that the request
has to be a valid SIP request and that out-of-band | has to be a valid SIP request and that out-of-band
signaling is not acceptable. signaling is not acceptable.
REQ-4: Mapping of existing schemes: Existing CSN schemes must be | REQ-4: Mapping of existing schemes: Existing CSN schemes must be
translatable to SIP-based systems. translatable to SIP-based systems.
REQ-5: No loss of information: For the CSN-IP-CSN case, there REQ-5: No loss of information: For the CSN-IP-CSN case, there
should be no loss of signaling information caused by should be no loss of signaling information caused by
transiting the IP network if both circuit-switched networks transiting the IP network if both circuit-switched networks
use the same priority scheme. Loss of information may be use the same priority scheme. Loss of information may be
unavoidable if the destination CSN uses a different unavoidable if the destination CSN uses a different
priority scheme from the origin. priority scheme from the origin.
One cannot assume that both CSNs are using the same One cannot assume that both CSNs are using the same
signaling protocol or protocol version, such as ISUP, so signaling protocol or protocol version, such as ISUP, so
that transporting ISUP objects in MIME [3,4] is unlikely to that transporting ISUP objects in MIME [3,4] is unlikely to
be sufficient. be sufficient.
REQ-6: Extensibility: Any naming scheme specified as part of the REQ-6: Extensibility: Any naming scheme specified as part of the
SIP indication should allow for future expansion. Expanded SIP indication should allow for future expansion. Expanded
naming schemes may be needed as resource priority is naming schemes may be needed as resource priority is
applied in additional private networks, or if VoIP-specific applied in additional private networks, or if VoIP-specific
priority schemes are defined. priority schemes are defined.
REQ-7: Separation of policy and mechanism: The SIP indication | REQ-7: Separation of policy and mechanism: The SIP indication
should not describe a particular detailed treatment, as it | should not describe a particular detailed treatment, as it
is likely that this depends on the nature of the resource | is likely that this depends on the nature of the resource
and local policy. Instead, it should invoke a particular | and local policy. Instead, it should invoke a particular
named policy. As an example, instead of specifying that a | named policy. As an example, instead of specifying that a
certain SIP request should be granted queueing priority, | certain SIP request should be granted queueing priority,
not cause preemption, but be restricted to three-minute | not cause preemption, but be restricted to three-minute
sessions, the request invokes a certain named policy that | sessions, the request invokes a certain named policy that
may well have those properties in a particular | may well have those properties in a particular
implementation. An IP-to-CSN gateway may need to be aware | implementation. An IP-to-CSN gateway may need to be aware
of the specific actions required for the policy, but the | of the specific actions required for the policy, but the
protocol indication itself should not. protocol indication itself should not.
Even in the CSN, the same MLPP indication may result Even in the CSN, the same MLPP indication may result
in different behavior for different networks. in different behavior for different networks.
REQ-8: Request-neutral: The SIP indication chosen should work REQ-8: Request-neutral: The SIP indication chosen should work
for any SIP request, not just, say, INVITE. for any SIP request, not just, say, INVITE.
REQ-9: Default behavior: Network terminals configured to use a REQ-9: Default behavior: Network terminals configured to use a
priority scheme may occasionally end up making calls in a priority scheme may occasionally end up making calls in a
skipping to change at page 11, line 17 skipping to change at page 12, line 30
elements work during an actual emergency. In particular, elements work during an actual emergency. In particular,
critical elements such as indication, authentication, critical elements such as indication, authentication,
authorization and call routing must be testable. Testing authorization and call routing must be testable. Testing
under load is desirable. Thus, it is desirable that the SIP under load is desirable. Thus, it is desirable that the SIP
indication is available continuously, not just during indication is available continuously, not just during
emergencies. emergencies.
REQ-16: 3PCC: The system has to work with SIP third-party call REQ-16: 3PCC: The system has to work with SIP third-party call
control. control.
7 Policy and Mechanism REQ-17: Proxy-visible: Proxies may want to use the indication to
influence request routing (see Section 7) or impose
Priority mechanisms can be roughly categorized by whether they use a additional authentication requirements.
priority queue for resource attempts or whether they preempt existing
resource uses (e.g., calls).
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.
Similarly, the precise relationships between labels, e.g., what
fraction of capacity is set aside for each priority level, is also a
matter of local policy. This is similar to how differentiated
services labels are handled.
8 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. Compared to a non-ETS request for the same destination, the
set of destinations may include UAs that are only supporting ETS
service
9 Relationship to Emergency Call Services
The resource priority mechanisms are used to have selected
individuals place calls with elevated priority during times when the
network is suffering from 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
mechanism, where non-emergency calls are marked as emergency calls.
(If the entity can recognize the request URI as an emergency call, it
would not need the resource priority mechanism.)
10 Security Requirements 10 Security Requirements
Any resource priority mechanism can be abused to obtain resources and Any resource priority mechanism can be abused to obtain resources and
thus deny service to other users. While the indication itself does thus deny service to other users. While the indication itself does
not have to provide separate authentication, any SIP request carrying not have to provide separate authentication, any SIP request carrying
such information has more rigorous authentication requirements than such information has more rigorous authentication requirements than
regular requests. Below, we describe authentication and authorization regular requests. Below, we describe authentication and authorization
aspects, confidentiality and privacy requirements, protection against aspects, confidentiality and privacy requirements, protection against
denial of service attacks and anonymity requirements. Additional denial of service attacks and anonymity requirements. Additional
skipping to change at page 14, line 16 skipping to change at page 14, line 16
to replay attacks. to replay attacks.
SEC-6: Cut-and-paste: The authentication mechanisms must be SEC-6: Cut-and-paste: The authentication mechanisms must be
resistant to cut-and-paste attacks. resistant to cut-and-paste attacks.
SEC-7: Bid-down: The authentication mechanisms must be resistant SEC-7: Bid-down: The authentication mechanisms must be resistant
to bid down attacks. to bid down attacks.
10.2 Confidentiality and Integrity 10.2 Confidentiality and Integrity
SEC-9: Confidentiality: All aspects of ETS are likely to be SEC-8: Confidentiality: All aspects of ETS are likely to be
sensitive and should be protected from unlawful intercept sensitive and should be protected from unlawful intercept
and alteration. In particular, requirements for protecting and alteration. In particular, requirements for protecting
the confidentiality of communications relationships may be the confidentiality of communications relationships may be
higher than for normal commercial service. For SIP, the To, higher than for normal commercial service. For SIP, the To,
From, Organization, Subject, Priority and Via header fields From, Organization, Subject, Priority and Via header fields
are examples of particularly sensitive information. Callers are examples of particularly sensitive information. Callers
may be willing to sacrifice confidentiality if the only may be willing to sacrifice confidentiality if the only
alternative is abandoning the call attempt. alternative is abandoning the call attempt.
Unauthorized users must not be able to discern that a Unauthorized users must not be able to discern that a
skipping to change at page 14, line 43 skipping to change at page 14, line 43
The act of authentication, e.g., by contacting a particular The act of authentication, e.g., by contacting a particular
server, itself may reveal that a user is requesting server, itself may reveal that a user is requesting
prioritized service. prioritized service.
SIP allows protection of header fields not used for SIP allows protection of header fields not used for
request routing via S/MIME, while hop-by-hop channel request routing via S/MIME, while hop-by-hop channel
confidentiality can be provided by TLS or IPsec. confidentiality can be provided by TLS or IPsec.
10.3 Anonymity 10.3 Anonymity
SEC-10: Anonymity: Some users may wish to remain anonymous to SEC-9: Anonymity: Some users may wish to remain anonymous to the
the request destination. For the reasons noted earlier, request destination. For the reasons noted earlier, users
users have to authenticate themselves towards the network have to authenticate themselves towards the network
carrying the request. The authentication may be based on carrying the request. The authentication may be based on
capabilities and noms, not necessarily their civil name. capabilities and noms, not necessarily their civil name.
Clearly, they may remain anonymous towards the request Clearly, they may remain anonymous towards the request
destination, using the network-asserted identity and destination, using the network-asserted identity and
general privacy mechanisms [6,7]. general privacy mechanisms [6,7].
10.4 Denial-of-Service Attacks 10.4 Denial-of-Service Attacks
SEC-11: Denial-of-service: ETS systems are likely to be subject SEC-10: Denial-of-service: ETS systems are likely to be subject
to deliberate denial-of-service attacks during certain to deliberate denial-of-service attacks during certain
types of emergencies. DOS attacks may be launched on the types of emergencies. DOS attacks may be launched on the
network itself as well as its authentication and network itself as well as its authentication and
authorization mechanism. authorization mechanism.
SEC-12: Minimize resource use by unauthorized users: Systems SEC-11: Minimize resource use by unauthorized users: Systems
should minimize the amount of state, computation and should minimize the amount of state, computation and
network resources that an unauthorized user can command. network resources that an unauthorized user can command.
SEC-13: Avoid amplification: The system must not amplify attacks SEC-12: Avoid amplification: The system must not amplify attacks
by causing the transmission of more than one packet or SIP by causing the transmission of more than one packet or SIP
request to a network address whose reachability has not request to a network address whose reachability has not
been verified. been verified.
11 Acknowledgements 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
Fred Baker, Scott Bradner, Ian Brown, Ken Carlberg, Janet Gunn, Fred Baker, Scott Bradner, Ian Brown, Ken Carlberg, Janet Gunn,
Kimberly King, Rohan Mahy and James Polk provided helpful comments. Kimberly King, Rohan Mahy and James Polk provided helpful comments.
12 Bibliography 13 Bibliography
[1] J. Lennox, H. Schulzrinne, and J. Rosenberg, "Common gateway [1] J. Lennox, H. Schulzrinne, and J. Rosenberg, "Common gateway
interface for SIP," RFC 3050, Internet Engineering Task Force, Jan. interface for SIP," RFC 3050, Internet Engineering Task Force, Jan.
2001. 2001.
[2] J. Lennox and H. Schulzrinne, "CPL: A language for user control [2] J. Lennox and H. Schulzrinne, "CPL: A language for user control
of internet telephony services," Internet Draft, Internet Engineering of internet telephony services," Internet Draft, Internet Engineering
Task Force, Nov. 2001. Work in progress. Task Force, Nov. 2001. Work in progress.
[3] E. Zimmerer, J. Peterson, A. Vemuri, L. Ong, F. Audet, M. Watson, [3] E. Zimmerer, J. Peterson, A. Vemuri, L. Ong, F. Audet, M. Watson,
skipping to change at page 16, line 9 skipping to change at page 16, line 17
progress. progress.
[6] J. Peterson, "A privacy mechanism for the session initiation [6] J. Peterson, "A privacy mechanism for the session initiation
protocol (SIP)," Internet Draft, Internet Engineering Task Force, protocol (SIP)," Internet Draft, Internet Engineering Task Force,
June 2002. Work in progress. June 2002. Work in progress.
[7] M. Watson, "Short term requirements for network asserted [7] M. Watson, "Short term requirements for network asserted
identity," Internet Draft, Internet Engineering Task Force, June identity," Internet Draft, Internet Engineering Task Force, June
2002. Work in progress. 2002. Work in progress.
13 Authors' Address 14 Authors' Address
Henning Schulzrinne Henning Schulzrinne
Dept. of Computer Science Dept. of Computer Science
Columbia University Columbia University
1214 Amsterdam Avenue 1214 Amsterdam Avenue
New York, NY 10027 New York, NY 10027
USA USA
electronic mail: schulzrinne@cs.columbia.edu electronic mail: schulzrinne@cs.columbia.edu
 End of changes. 30 change blocks. 
151 lines changed or deleted 162 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/