& $|$ & \header{Hide}                  & ; Section~\ref{sec:Hide}\\

\header{Hide}               &  R     & rm & o & o & o & o & o & o \\

\subsection{\header{Hide}}
\label{sec:Hide}

A client uses the \header{Hide} request header field to indicate that it
wants the path comprised of the \header{Via} header fields
(Section~\ref{sec:Via}) to be hidden from subsequent proxies and user
agents.  It can take two forms:  \header{Hide:  route} and \header{Hide: 
hop}.  \header{Hide} header fields are typically added by the client
user agent, but {\MAY} be added by any proxy along the path.

If a request contains the ``\header{Hide:  route}'' header field, all
following proxies {\SHOULD} hide their previous hop.  If a request
contains the ``\header{Hide:  hop}'' header field, only the next proxy
{\SHOULD} hide the previous hop and then remove the \header{Hide}
option unless it also wants to remain anonymous.

\begin{changebar}
A server hides the previous hop by encrypting the ``\header{host}'' (in
both \header{sent-by} and \header{via-received}),
``\header{port}'', ``\header{maddr}''
\end{changebar}
parts of the top-most \header{Via} header field with an algorithm of its
choice.  Servers {\SHOULD} add additional ``salt'' to the
``\header{host}'' and ``\header{port}'' information prior to encryption
to prevent malicious downstream proxies from guessing earlier parts of
the path based on seeing identical encrypted \header{Via} headers. 
Hidden \header{Via} fields are marked with the ``\header{hidden}''
\header{Via} option, as described in Section~\ref{sec:Via}.

A server that is capable of hiding \header{Via} headers {\MUST}
attempt to decrypt all \header{Via} headers marked as ``hidden'' to
perform loop detection.  Servers that are not capable of hiding can
ignore hidden \header{Via} fields in their loop detection algorithm.

\motivation{If hidden headers were not marked, a proxy would have to
decrypt all headers to detect loops, just in case one was encrypted, as
the \header{Hide: hop} option may have been removed along the way.}

\cbdelete

A client requesting ``\header{Hide:  route}'' can only rely on keeping
the request path private if it sends the request to a trusted proxy. 
Hiding the route of a SIP request is of limited value if the request
results in data packets being exchanged directly between two user
agents.

\begin{changebar}
The use of \header{Hide} header fields is discouraged unless path
privacy is truly needed as \header{Hide} fields impose extra processing
costs proxies.
\end{changebar}

The encryption of \header{Via} header fields is described in more detail
in Section~\ref{sec:security}.

The \header{Hide} header field has the following syntax:
\begin{syntax}
Hide & = & "Hide" ":" ( "route" $|$ "hop" $|$ other-hide )\\
other-hide & = & token\\
\end{syntax}

Via

For reasons of privacy, a client or proxy may wish to hide its
\header{Via} information by encrypting it (see Section~\ref{sec:Hide}). 
The ``\header{hidden}'' parameter is included if this header field was
hidden by the upstream proxy (see \ref{sec:Hide}).  Note that privacy of
the proxy relies on the cooperation of the next hop, as the next-hop
proxy will, by necessity, know the IP address and port number of the
source host.

security.tex:
SIP \header{Via} fields are used to route a response back along the path
taken by the request and to prevent infinite request loops.  However,
the information given by them can also provide useful information to an
attacker.  Section \ref{sec:Hide} describes how a sender can request
that Via fields be encrypted by cooperating proxies without compromising
the purpose of the \header{Via} field.

\item hop-by-hop encryption of \header{Via} fields to hide the route a
request has taken.

\subsubsection{\header{Via} field encryption}

When \header{Via} header fields are to be hidden, a proxy that receives
a request containing an appropriate ``\header{Hide:  hop}'' header field
(as specified in section \ref{sec:Hide}) {\SHOULD} encrypt the header
field.  As only the proxy that encrypts the field will decrypt it, the
algorithm chosen is entirely up to the proxy implementor.  Two methods
satisfy these requirements:

\begin{itemize}
\item The server keeps a cache of \header{Via} header fields and the
associated \header{To} header field, and replaces the \header{Via}
header field with an index into the cache.  On the reverse path, take
the \header{Via} header field from the cache rather than the message.

This is insufficient to prevent message looping, and so an additional ID
{\MUST} be added so that the proxy can detect loops.  This {\SHOULDNOT}
normally be the address of the proxy as the goal is to hide the route,
so instead a sufficiently large random number {\SHOULD} be used by the
proxy and maintained in the cache.

It is possible for replies to get directed to the wrong originator if
the cache entry gets reused, so great care needs to be taken to ensure
this does not happen.

\item The server {\MAY} use a secret key to encrypt the \header{Via}
field, a timestamp and an appropriate checksum in any such message with
the same secret key.  The checksum is needed to detect whether
successful decoding has occurred, and the timestamp is required to
prevent possible replay attacks and to ensure that no two requests
from the same previous hop have the same encrypted \header{Via} field. 
This is the preferred solution.

\end{itemize}


