Subject: Hide interaction with Record-Route

From: Alan Johnston <[email-masked]>
Date: Thu, 17 Jun 1999 09:10:38 -0500

A question has come up relating to interactions between the Hide header
and the Record-Route header.

What is the proper operation of a proxy if it receives a SIP request
like this (body not shown for clarity):

INVITE sip:[email-masked] SIP/2.0
Via: SIP/2.0/UDP sip2.wcom.com
Via: SIP/2.0/UDP sip1.wcom.com
From: sip:[email-masked]
To: sip:[email-masked]
Call-ID: [email-masked]
CSeq: 1 INVITE
Record-Route: sip2.wcom.com
Hide: hop

In this case, sip2 is in the required routing path, but it wants its
address hidden from proxies and clients other than the trusted proxy,
sip3.

Without considering the interaction between Record-Route and Hide and
assuming sip3 is not in the required routing path, it would forward:

INVITE sip:[email-masked] SIP/2.0
Via: SIP/2.0/UDP sip3.wcom.com
Via: SIP/2.0/UDP jhdflkjHkljhHkJhLKG7u6tUfygIUkhlkjHgKJGlkjghkLJ; hidden
Via: SIP/2.0/UDP sip1.wcom.com
From: sip:[email-masked]
To: sip:[email-masked]
Call-ID: [email-masked]
CSeq: 1 INVITE
Record-Route: sip2.wcom.com

(Where the random characters represent the encrypted sip2 address.)
However, the hidden sip2 address is present in the Record-Route header
for anyone to see.  A possible solution to this is to encrypt the
Record-Route hostname as well.  However, the proxy sip3 would then have
to insert itself into the Record-Route header since it is the only proxy
that could de-crypt the encrypted Record-Route header entry for sip2. 
In this case, the forwarded message would look like:

INVITE sip:[email-masked] SIP/2.0
Via: SIP/2.0/UDP sip3.wcom.com
Via: SIP/2.0/UDP jhdflkjHkljhHkJhLKG7u6tUfygIUkhlkjHgKJGlkjghkLJ; hidden
Via: SIP/2.0/UDP sip1.wcom.com
From: sip:[email-masked]
To: sip:[email-masked]
Call-ID: [email-masked]
CSeq: 1 INVITE
Record-Route: sip3.wcom.com, NafMdaHksjfasJKHLKJGHLkjsdfkOalskljHKH;
hidden

If this is the correct behavior, the syntax for Record-Route and Route
would need to be changed to include encrypted addresses.

Another possible scenario is where the UAC sends a request that includes
both a Contact header and a Hide header. Probably the correct behavior
in that case would be for the proxy to remove the Contact header rather
then encrypt it.

Comments?

Thanks,
Alan Johnston
MCI WorldCom
314-342-7360

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Jun 1999 20:52:37 -0400

> and the Record-Route header.

Good catch.

> would need to be changed to include encrypted addresses.

Actually, sip3 does not need to be on the Record-Route path for this to
work in the forward direction. sip3 will need to decrypt the
Record-Route header as it comes back in the 200 OK. It will receive this
200 OK whether or not its on the Record-Route path. The tricky part is
that unlike Vias, Record-Routes aren't stripped. So, sip3 may have to
attempt to decrypt each encryped Record-Route until it has found the one
for sip2 (if sip3 inserted its own Record-Route and didn't set Hide:
hop, this operation is easier). 

Unfortunately, requests in the reverse direction will also be routed
(using a reversed version of the list). This is not in the base spec,
but has been identified previously as an omission. In this case, the
Record-Route list received at the UAS will be completely encrypted. The
Route headers generated will therefore be encrypted as well (note they
are not encrypted at the caller). As the reverse request is forwarded,
each proxy must try to decrypt the Record-Route used by the next hop. In
this direction, the problem you point out does exist - sip3 must be on
the Record-Route path.

However, requests from the originator will contain Route headers which
must be ENCRYPTED rather than decrypted, presuming we want to safeguard
the Route headers too. This is particularly nasty, since the proxies
can't easily tell whether they are in the "forward" or "reverse"
directions from the message alone. The behavior is different in each
case - one is try to encrypt, and the other is try to decrypt. 

It was never that clear to me how useful hiding the Via fields is. Other
stuff which seems more important (To and From) goes in the clear. Given
the complication here, I think we need to be sure its worth pursuing a
solution. I don't know of anyone who has implemented Via hiding yet
(speak up if you have), and this feature seemed a candidate for
potential removal at draft if no one found it useful. 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: Lars Berggren <[email-masked]>
Date: Fri, 18 Jun 1999 11:08:23 +0200

> > would need to be changed to include encrypted addresses.

Yes, I think so.

> the Route headers too.

Must they? I'm not sure I understand what you mean, correct me if I am
wrong, but the route list does not contain any upstream addresses to
encrypt since each hop removes the next hop from the list, does it? Or
is it the downstream addresses you mean?

> This is particularly nasty, since the proxies

Can not this be solved with a ;hidden parameter similar to the Via
header?
 
> potential removal at draft if no one found it useful.

I think Via hiding is a very useful feature for NATs, where the task is
to hide local addresses. The To and From fields can contain
host-independent globally reachable URLs which, unlike the Via, not has
to convey the specific address of the caller/callee and in that case can
go in the clear. However, I don't see much use for the Hide header field
for NATs, since the NAT probably will hide the previous Via whether the
request did or did not contain the Hide header. It is the syntax of the
Via field that is of importance here, the allowing of encrypted
addresses and the ;hidden parameter. I think a similar construct for
Record-Routes and Routes could be very useful.

/Lars

-- 
Lars Berggren       <[email-masked]>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 19 Jun 1999 01:09:57 -0400

Lars Berggren wrote:

> is it the downstream addresses you mean?

Sorry; you're right. There would be no need for encryption as they are
stripped.

> Can not this be solved with a ;hidden parameter similar to the Via

Yes, I think that would work.

> to hide local addresses.

The task of a NAT is not to hide these addresses, but to translate them
because they aren't globally routable. Fortunately, the Route and Via
headers don't need to contain globally routable addresses, since they
are interpreted only by hosts within the same context where the
addresses are valid. 

Even if a nat did wish to hide the internal addresses for security,
there are other ways to do this besides the hiding mechanism. The NAT
could simply remove both the Route and Via headers so far, and store
them in a table indexed by the transaction and Call-ID. The forwarded
request then looks as if it was originated from the NAT. When the
response comes, the Via and Record-Routes are added back in as the
response is forwarded. Same for requests in the reverse direction - the
Route headers would be placed in the request based on the Record-Route
headers in the table. Unfortunately, the NAT has to hold these entries
for a while (until the call is over). But, this is the same amount of
time a NAT using the hiding mechanism would need to remember how to
decrypt the Record-Route headers. These headers cannot just be encrypted
as is; they must be encrypted with some random salt otherwise the path
can still be guessed. Thus, to decrypt the Route headers in requests in
the reverse direction, the proxy must remember what random number it
used, for the duration of the call. 

The SDP will anyway contain an IP address and port for media that cannot
be hidden.

-Jonathan R.

---

From: Lars Berggren <[email-masked]>
Date: Mon, 21 Jun 1999 13:45:31 +0200

Jonathan Rosenberg wrote:
...
> are interpreted only by hosts within the same context where the

Yes, you are right, the primary task is to translate addresses, but in
addition, there may be reasons to hide addresses.

> used, for the duration of the call.

This is correct. However I think it is less resource consuming to store
that random number than storing Via- and Route-lists and this is the
reason why a nat might want to do so.

> The SDP will anyway contain an IP address and port for media that cannot

Yes, they can't be hidden and here is where the translation has to be
done. Since the NAT has to keep state for the translation during the
call, there is no need to hide the SDP addresses in the SIP message.
/Lars

---

From: Alan Johnston <[email-masked]>
Date: Mon, 21 Jun 1999 15:03:51 -0500

>From the responses seen to date, it seems:

1. There is interest in the SIP spec support for the Hide header and
encrypted Via fields.

2. The SIP spec should be changed to permit encrypted Record-Route and
Route fields with the "hidden" parameter in much the same way encrypted
Via fields are allowed.

3. Proper behavior of a server which encrypts a Via header is to also
encrypt an associated entry in a Record-Route header if present.  The
server will also need to include itself in the Record-Route header to
ensure it remains in the path for future messages using the Route header
with the encrypted field.

Any other issues or comments?

Thanks,
Alan Johnston
MCI WorldCom
314-342-7360

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 21 Jun 1999 23:12:59 +0100

> 1. There is interest in the SIP spec support for the Hide header and

I guess silence probably signifies a lack of strong feelings. Personally
I'd be happy to see Hide disappear. It sounds like the rules for how to
treat this header is quickly becoming rather complicated and IMHO that's
a good reason for dropping it, especially if we think it may not really
be needed.

-- 
Anders Kristensen <[email-masked]>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 21 Jun 1999 18:35:10 -0400

> a good reason for dropping it, especially if we think it may not really

I'm also unconvinced. It seems that the same effect can be achieved by
stripping the Record-Route/Route/Contacts and re-attaching them if
needed, as I pointed out in my last mail. Lars is correct in that it is
probably more efficient (storage wise, NOT computation wise) to use the
Hiding mechanism. But, given the complexity (I'm not convinced we've
fully worked it out yet), its not clear its worth it.

-Jonathan R.

---

From: Mark Handley <[email-masked]>
Date: Tue, 22 Jun 1999 16:43:29 -0700

>Any other issues or comments?

I think you're correct here about the proper behavior.

In general, I believe it's vital for SIP to be able to maintain
privacy and anonymity where required.  This may even be a legal
requirement in some application domains.

SIP requests and responses can, in general, reveal quite a bit of
information by the path they take through a proxy chain.  Having
mechanisms in SIP to hide or remove this information without breaking
SIP behavior is therefore of great importance.

For server-side privacy, the combination of relaying, carefully placed
proxies for the callee, and stripping the Via fields can give complete
privacy.  The path is not revealed unless a proxy wishes its presence
to be known and adds record route.  Final responses (eg 200) would
appear to reveal location, but this is not necessarily the case
because the server can, on receipt of a request, contact an
anonymizing SIP/RTP proxy to anonymize the actual end-point location,
and can give this location in the 200 response and the SDP.  Thus we
can currently have complete server-side privacy with SIP.

What we'd like to be able to do is offer the same privacy for the
caller too.  Again, this requires the use of a trusted proxy that
outgoing calls get routed through.  If this proxy is stateful, then it
can easily anonymize requests by stripping identifying fields, but we
have to be very careful about not messing up behavior by stripping
arbitrary foields when the proxy and the client are from different
vendors.  Thus you have to have this behavior carefully specified.
The requirement for anonymity is a client requirement, not a proxy
requirement, so we only want this behavior when the client actually
requests it.  Also we don't want proxies to have to be stateful.

So, what we ended up with was a way for the client to signal that they
care about privacy of the SIP routing information ("hide: route").
This can then be implemented by the proxy stripping Via fields and
storing them, or by encrypting them which allows for stateful proxies.
The model of receiver encrypts (or strips) is natural, because there's
no location information in the first Via field that isn't already
available from the source address of the request packets.  Clearly it
has little security once you get beyond the last trusted outgoing
proxy, but it is a solid mechanism until that point.  It also allows
onion-security, where each successive outgoing proxy is responsible
for hiding everything inside that trust boundary (useful for very
paranoid organizations).  What the client puts as a contact header and
in the SDP is it's own responsibility, is arranged out-of-band with a
trusted anonymizing proxy (perhaps with a secondary SIP request), and
shouldn't be closely tied to the primary signalling path.

The "hide: hop" mechanism is explictly because a request can chain
into and out of a paranoid location, and allows limited explicit
signalling to the border of the paranoid region.  This is a little
weak, compared to hide:route, but still appears to be of use.  The
reason not to use hide-route is because didn't want to confuse proxy
privacy signalling with client privacy signalling.  In general you'd
like all such intentions to be explicit rather than implicit.

Now the issue of hide interaction with record-route is something we'd
missed, and does need addressing.  The privacy requirements are
identical to Via, and the same mechanism seems perfectly appropriate.
I'd go further to suggest that outgoing trusted proxies would normally
set record-route if hide:route is set in order to ensure that
subsequent requests also pass through them and are therefore also
anonymized in the same way.

I hope this explains a little behind the motivation for the hide
field, and why I *strongly* believe it's crucial for SIP deployment in
some problem domains.

Cheers,
	Mark