\documentclass[11pt]{article}
\usepackage{times}
\usepackage{graphics}
\usepackage{ifthen}
\usepackage{i-d}
\usepackage{html}
\usepackage{txtpsfig}
\usepackage{tight}
\usepackage{html}
\usepackage[dvips]{changebar}
\usepackage{multibib}
\newcites{norm,inform}{Normative References,Informative References}

\title{Requirements for Resource Priority Mechanisms for the Session
Initiation Protocol}
\author{H. Schulzrinne}
\shorttitle{IEPREP SIP Requirements}
\filename{draft-ietf-ieprep-sip-reqs-03}
\wg{IEPREP}
\expires{May 2003}
\address{Columbia U.}
\pubdate{\today}
\input{../defs}

\begin{document}
\maketitle
\begin{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). 
\end{abstract}

\section{Introduction}

During emergencies, communications resources including telephone
circuits, IP bandwidth and gateways between the circuit-switched and IP
networks may become congested.  Congestion can occur due to heavy usage,
loss of resources caused by the natural or man-made disaster and attacks
on the network during man-made emergencies.  This congestion may make it
difficult for persons charged with emergency assistance, recovery or law
enforcement to coordinate their efforts.  As IP networks become part of
converged or hybrid networks along with public and private
circuit-switched (telephone) networks, it becomes necessary to ensure
that these networks can assist during such emergencies.

There are many IP-based services that can assist during emergencies. 
This memo only covers requirements for real-time communications
applications involving SIP, including voice-over-IP, multimedia
conferencing and instant messaging/presence.  

This document takes no position as to which mode of communication is
preferred during an emergency, as such discussion appears to be of
little practical value.  Based on past experience, real-time
communications is likely to be an important component of any overall
suite of applications, particularly for coordination of
emergency-related efforts.

As we will describe in detail below, such Session Initiation Protocol
(SIP) \citenorm{rfc3261} applications involve at least five different
resources that may become scarce and congested during emergencies.  In
order to improve emergency response, it may become necessary to
prioritize access to such resources during periods of emergency-induced
resource scarcity.  We call this ``resource prioritization''.

This document describes requirements rather than possible existing or
new protocol features.  Although it is scoped to deal with SIP-based
applications, this should not be taken to imply that mechanisms have to
be SIP protocol features such as header fields, methods or URI
parameters.

The document is organized as follows.  In Section~\ref{sec:terminology},
we explain core technical terms and acronyms that are used throughout
the document.  
Section~\ref{sec:resources} describes the five types of resources that
may be subject to resource prioritization.  Section~\ref{sec:hybrid}
enumerates four network hybrids that determine which of these resources
are relevant.  Since the design choices may be constrained by the
assumptions placed on the IP network, Section~\ref{sec:models} 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~\ref{sec:ecs} 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~\ref{sec:routing}.

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~\ref{sec:policy} discusses the
call-by-value (specification of mechanisms) and call-by-reference
(invoke labeled policy) distinction.

Based on these discussions, Section~\ref{sec:general} 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~\ref{sec:security}).  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.

\section{Terminology}
\label{sec:terminology}

\begin{description}
\item[CSN:] Circuit-switched network, encompassing both private (closed)
networks and the public switched telephone network (PSTN).

\item[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.

\item[Request:] In this document, we define ``request'' as any SIP
request.  This includes call setup requests, instant message requests
and event notification requests.

\end{description}

\section{Resources}
\label{sec:resources}

Prioritized access to at least five resource types may be useful:

\begin{description}
\item[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.

\item[CSN resources:] Resources in the CSN itself, away from the access
gateway, may be congested.  This is the domain of traditional resource
prioritization as MLPP and GETS, where circuits are granted to ETS
communications based on queueing priority or preemption (if allowed by
local telecommunication regulatory policy and local administrative
procedures).  A gateway may also use alternate routing
(Section~\ref{sec:policy}) 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.

\item[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.

\item[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.)

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.

\item[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
\citeinform{rfc3050} and CPL \citeinform{draft-ietf-iptel-cpl} 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 isssue 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.

\motivation{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.}

\end{description}

There is no requirement that a single mechanism be used for all five
resources.

\section{Network Topologies}
\label{sec:hybrid}

We consider four types of combinations of IP and circuit-switched
networks.

\begin{description}
\item[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.

\item[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.

\item[CSN-to-IP (IP at the end):] A call originates in the CSN and
terminates, via an Internet telephony gateway, in the IP network.

\item[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.

\end{description}

The bridging model (IP-CSN-IP) can be treated as the concatenation of
the IP-to-CSN and CSN-to-IP cases.

It is worth emphasizing that CSN-to-IP gateways are unlikely to know
whether the final destination is in the IP network, the CSN or, via SIP
forking, in both.

These models differ in the type of controllable resources, identified as
gateway, CSN, IP network resources, proxy and receiver.  Items marked as
(x) are beyond the scope of this document.

\begin{flushleft}
\begin{tabular}{llllll}
Topology       & Gateway & CSN & IP & proxy & receiver\\
\hline
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)\\
\end{tabular}
\end{flushleft}

\section{Network Models}
\label{sec: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.

\begin{description}
\item[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.

\item[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.

\item[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.

\item[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.

\motivation{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.}

\end{description}

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 is an example of an ``opportunistic'' network,
allowing use from most unmodified telephones, while MLPP systems are
typically pre-configured.

\section{Relationship to Emergency Call Services}
\label{sec:ecs}

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 \emph{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.)

\section{SIP Call Routing}
\label{sec: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.

\section{Policy and Mechanism}
\label{sec:policy}

Most priority mechanisms can be roughly categorized by whether they:
\begin{itemize}
\item use a priority queue for resource attempts,

\item make additional resources available (e.g., via alternate routing
(ACR)), or

\item preempt existing resource users (e.g., calls.) 
\end{itemize}

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.

\section{Requirements}
\label{sec:general}

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~\ref{sec:security}.  We will refer to the feature as a ``SIP
indication'' and to requests carrying such an indication as ``labelled
requests''.

\begin{description}
\item[REQ-1:  Not specific to one scheme or country:] The SIP indication
should support existing and future priority schemes.  For example, there
are currently at least four priority schemes in widespread use:  Q.735,
also implemented by the U.S.  defense telephone network (``DSN'' or
``Autovon'') and NATO, has five levels, the United States GETS
(Government Emergency Telecommunications Systems) scheme with implied
higher priority and the British Government Telephone Preference Scheme
(GTPS) system, which provides three priority levels for receipt of dial
tone.

The SIP indication may support these existing CSN priority schemes
through the use of different namespaces.

Private-use namespaces may also be useful for certain applications.

\item[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.

\item[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.

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. 

\item[REQ-4:  Mapping of existing schemes:] Existing CSN schemes must be
translatable to SIP-based systems.

\item[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 \citeinform{rfc3204,rfc3372} is unlikely to be sufficient.

\item[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.

\item[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.

\motivation{Even in the CSN, the same MLPP indication may result in
different behavior for different networks.}

\item[REQ-8:  Method-neutral:] The SIP indication chosen should work
for any SIP method, not just, say, {\INVITE}. 

\item[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 priority marking and
appropriate authentication. This is a matter of local policy.

\item[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.)

\motivation{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.}

\item[REQ-11:  Identity-independent:] The user identity, such as the
\header{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.

\item[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.

\item[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.)

\item[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 support the
priority scheme.  However, entities should be able discover whether a
network element supports it or not.

\item[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.

\item[REQ-16:  3PCC:] The system has to work with SIP third-party call
control.

\item[REQ-17:  Proxy-visible:] Proxies may want to use the indication to
influence request routing (see Section~\ref{sec:routing}) or impose
additional authentication requirements. 

\end{description}

\section{Security Requirements}
\label{sec:security}

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 \citeinform{draft-ietf-ieprep-security}.

\subsection{Authentication and Authorization}

\begin{description}

\item[SEC-1:  More rigorous:] Prioritized access to network and end
system resources enumerated in Section~\ref{sec:resources} imposes
particularly stringent requirements on authentication and authorization
mechanisms since access to prioritized resources may impact overall
system stability and performance, not just result in theft of, say, a
single phone call.

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.

\item[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.

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 oneself via a DTMF
sequence.

Given the urgency during emergency events, normal statistical fraud
detection may be less effective, thus placing a premium on reliable
authentication.

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.

\item[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.

\item[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. 

\item[SEC-5: Replay:] The authentication mechanisms must be resistant to
replay attacks.

\item[SEC-6: Cut-and-paste:] The authentication mechanisms must be resistant to
cut-and-paste attacks.

\item[SEC-7: Bid-down:] The authentication mechanisms must be resistant to
bid down attacks.

\end{description}

\subsection{Confidentiality and Integrity}

\begin{description}

\item[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 \header{To}, \header{From},
\header{Organization}, \header{Subject}, \header{Priority} and
\header{Via} header fields are examples of particularly sensitive
information.  Callers may be willing to sacrifice confidentiality if the
only alternative is abandoning the call attempt. 

Unauthorized users must not be able to discern that a particular request
is using a resource priority mechanism, as that may reveal sensitive
information about the nature of the request to the attacker. 
Information not required for request routing should be protected
end-to-end from intermediate SIP nodes.

The act of authentication, e.g., by contacting a particular server,
itself may reveal that a user is requesting prioritized service.

\motivation{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.}

\end{description}

\subsection{Anonymity}

\begin{description}

\item[SEC-9:  Anonymity:] Some users may wish to remain anonymous to the
request destination.  For the reasons noted earlier, users have to
authenticate themselves towards the network carrying the request.  The
authentication may be based on capabilities and noms, not necessarily
their civil name.  Clearly, they may remain anonymous towards the
request destination, using the network-asserted identity and general
privacy mechanisms
\citeinform{draft-ietf-sip-privacy-general,draft-ietf-sipping-nai-reqs}.

\end{description}

\subsection{Denial-of-Service Attacks}

\begin{description}
\item[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. 

\item[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. 

\item[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.

\end{description}

\section{Security Considerations}
\label{sec:security_considerations}

Section~\ref{sec:security} discusses the security issues related to
priority indication for SIP in detail and derives requirements for the
SIP indicator.  As discussed in Section~\ref{sec:ecs}, identification of
priority service should avoid multiple concurrent mechanisms, to avoid
allowing attackers to exploit inconsistent labeling. 

\section{Acknowledgements}

Ran Atkinson, Fred Baker, Scott Bradner, Ian Brown, Ken Carlberg, Janet
Gunn, Kimberly King, Rohan Mahy and James Polk provided helpful
comments.

\bibliographystylenorm{ieeetr_url}
\bibliographynorm{string,rfc,itu}
\bibliographystyleinform{ieeetr_url}
\bibliographyinform{string,rfc,i-d,itu,ansi}

\section{Authors' Address}
\begin{flushleft}
Henning Schulzrinne\\
Dept. of Computer Science\\
Columbia University\\
1214 Amsterdam Avenue\\
New York, NY 10027\\
USA\\
electronic mail: {\sf schulzrinne@cs.columbia.edu}
\end{flushleft}

\input{copyright}

\end{document}
