\section{Addressing the IEPREP Requirements}
\label{sec:requirements}

[This section may be removed before publication, depending on WG/IESG
feedback.]

Below, we describe how the mechanism in this memo as well as plausible
alternatives address the requirements in
\citeinform{draft-ietf-ieprep-sip-reqs}.  For each requirement, we
indicate what existing mechanism can be used or what candidate
extensions might be suitable.  In general, none of the currently
standardized or proposed SIP features indicate whether a request makes
special claims to SIP-mediated resources or not.  (The \header{Priority}
header indicates the urgency to the human recipient of the request and
is orthogonal to this issue.)

In general, SIP offers four mechanisms to convey protocol semantics: 
URIs scheme (US) or parameter (UP), header fields (H), request methods
(M), caller preferences (C) and body content (B).

Thus, there are three choices:

\begin{description}
\item[Deduce:] Information in U, H, M, C or B is used to deduce the
resource priority demand.

\item[New:] A new H, M, C or B is added.

\item[Out-of-band:] Some other protocol indicates the choice.
\end{description}

Where applicable, we indicate which of these three approaches and which
element might be suitable.

\subsection{General Requirements}
\label{sec:general}

\begin{description}
\item[REQ-1:  Not specific to one scheme or country:] This requirement
implies that any SIP indication is flexible enough to accommodate a
variety of namespaces. There currently is no indication, so current SIP
cannot satisfy the requirement.

\item[REQ-2:  Independent of particular network architecture:] This
requirement rules out use of a new URI type (U), since all
SIP-addressable resources need to be included. It also makes an
out-of-band protocol difficult, as that typically pre-supposes support
from network elements such as firewalls.

\item[REQ-3:  Invisible to network (IP) layer:]  This requirement makes
use of out-of-band mechanisms difficult. Out-of-band mechanisms also
would have to be directed to the all the same locations that the SIP
request travels, adding difficulty.

\item[REQ-4:  Mapping of existing schemes:] This requirement has similar
implications as REQ-1.  It calls for the ability to accommodate
multi-valued enumerations of priority levels.

\item[REQ-5:  No loss of information:] This requirement stipulates that
there cannot be a many-to-one mapping, e.g., from some scheme to a set
of integers, since information about the original scheme would be lost.

\item[REQ-6:  Extensibility:] This requirement indicates the need for an
IANA registry to add additional items later.

\item[REQ-7:  Separation of policy and mechanism:] The mechanism must be
labels, not prescriptions for detailed call handling.

\item[REQ-8:  Method-neutral:] This rules out adding a new method that
calls for prioritized handling.

\item[REQ-9:  Default behavior:] This requirement only indicates that
the specification of any such scheme needs to address default behavior
in elements that expect to receive such an indication.

\item[REQ-10:  Address-neutral:] This requirement rules out the use of
special URIs or a new URI type. It may, however, be satisfied with a new
URI parameter on all URI schemes that may be carried in SIP. This
requirement is satisfied by H, M, B, and C.

\item[REQ-11:  Identity-independent:] This rules out the use of a
special \header{From} value.

\item[REQ-12:  Independent of network location:] This requirement rules
out the use of the \header{Contact} header or \header{Via} information.

\item[REQ-13:  Multiple simultaneous schemes:] This requirement mandates
that the indication allow a list of names.

\item[REQ-14:  Discovery:] This requirement argues for the use of
standard SIP negotiation mechanisms to determine the capabilities of the
other side, such as \header{Require}, \header{Proxy-Require} or
{\OPTIONS}.

\item[REQ-15:  Testing:] It does not appear that this adds additional
protocol requirements.

\item[REQ-16:  3PCC:] All mechanisms indicated appear to satisfy this
requirement.

\item[REQ-17:  Proxy-visible:] This requirement rules out the use of
message bodies, since these are not meant to be inspected or modified by
proxies.

\end{description}

Given REQ-8, REQ-10, REQ-11, there does not appear to be an existing
indication from which a recipient can reliably deduce resource priority. 
In addition, mechanisms B, M, and US fail one or more requirements,
leaving mechanisms H, C and UP.

UP requires that all SIP schemes be fitted with this parameter and thus
may make satisfying REQ-10 difficult.

Caller preferences describe desired capabilities and properties of the
end system and are used to select among a set of candidate locations.
This does not match the semantics desired here.

Thus, we will focus our attention below on the H and UP mechanisms.

The information that needs to be conveyed according to REQ-1, REQ-4,
REQ-5, REQ-10, REQ-11, and REQ-12 appears to be more suitable for a
request header.  It logically does not describe the destination or
source, but rather a property of the request. URI parameters are meant
to describe properties of the

Also, there is currently no mechanism in place to negotiate support for
URI parameters.

\subsection{Security Requirements}
\label{sec:req-security}

\begin{description}

\item[SEC-1:  More rigorous:] SIP-related mechanisms, such as Digest
authentication and hop-by-hop authentication, offer suitably strong
authentication mechanisms.

However, Digest authentication can currently only provide integrity of
the method, request URI and body, not header fields.  Thus, an adversary
could remove the indication header without detection.  However, that is
not likely to be more disruptive than simply removing the whole request
or modifying the destination address.

Modification of the indication is not likely to be useful to an
adversary unless some form of trust domain \citeinform{rfc3324} is used
where one element authenticates the request at a lower priority, the
adversary modifies it to a higher one and then abuses those privileges
in later SIP elements that trust the first element.  Otherwise,
increasing the priority will only incur additional authentication
requirements and likely cause the request to fail.

The discussion in \citeinform{draft-mahy-sipping-smime-vs-digest}
investigates how signed SIP message bodies may be used to address this
issue.

\item[SEC-2:  Attack protection:] This is a generic SIP requirement.
Denial of service issues are discussed at length in \citenorm{rfc3261}.
The reader is referred to that document for further details.

\item[SEC-3:  Independent of mechanism:] The candidate mechanisms work
with all existing SIP security techniques.

\item[SEC-4:  Non-trusted end systems:] This requirement suggests the
use of one-time passwords in SIP. This may be implementable on top of
the existing Digest mechanism, but no such specification exists.

\item[SEC-5: Replay:] The approved SIP authentication mechanisms address
this concern.

\item[SEC-6: Cut-and-paste:] The approved SIP authentication mechanisms address
this concern.

\item[SEC-7: Bid-down:] This concern is addressed by [stalled Digest draft]. 

\item[SEC-8:  Confidentiality:] If H or UP are used, body encryption is
not effective, so that channel security is called for. Currently, SIP
offers the use of IPsec and TLS.

\item[SEC-9:  Anonymity:] The network-asserted identity and general
privacy mechanisms \citeinform{rfc3323,rfc3325} are applicable.

\item[SEC-10:  Denial-of-service:] See SEC-2.

\item[SEC-11:  Minimize resource use by unauthorized users:] See SEC-2.

\item[SEC-12:  Avoid amplification:] See SEC-2.

\end{description}

