Subject: [SIP] VIA header encryption?

From: "Arnoud van Wijk (ELN)" <[email-masked]>
Date: Mon, 26 Feb 2001 12:49:52 +0100

Hello everybody.
I have the following question.
When a SIP server receives a SIP message, it will insert itself into the VIA header en most likely also encrypt it.
Is there a consensus or "rule" to say that the border (proxy) SIP server of a network (the first SIP proxy of a network where external SIP messages enter the network before getting forwarded to other SIP servers inside the network)is not allowed to encrypt the VIA header?

My undestanding is that the VIA header encryption is desired to prevent others to read the internal SIP traffic pathway of a network. By encrypting all the VIA headers but the top most one by a bordering SIP proxy should be enough. (the top most header is the proxy itself in this case).

Why?

In this way, we can identify a network domain via the bordering proxies. Asuming that those proxies do not encrypt the VIA header after adding themself into the VIA header. This can be useful if a certain network is spanned over 6 seperate domains.

Any suggestions?

Thanks!

Arnoud van Wijk

_______________________________________________________________
ERICSSON EUROLABS NETHERLANDS BV
Arnoud van Wijk
Research & Development (ELN/V)
Charging Competence Centre
Fax: +31-161 247569  Mobile: +31-6-10782760 (SMS only!)

Ericsson EuroLab Netherlands b.v.
P.O. Box 8
5120 AA Rijen
The Netherlands
mailto:[email-masked] 
Ericsson Homepage: http://www.ericsson.se
Ericsson Intranet: http://www.etm.ericsson.se/Abacus_lab/
_______________________________________________________________

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Neil Deason <[email-masked]>
Date: Mon, 26 Feb 2001 13:05:24 +0000

> Is there a consensus or "rule" to say that the border (proxy) SIP server of a network (the first SIP proxy of a network where external SIP messages enter the network before getting forwarded to oth…

In a 3GPP network encryption of Via headers may be likely,
in RFC2453bis based one it isn't. Remember Via hiding was 
removed from the bis 02 spec due to concerns that it:
 
- interferes with loop detection
- operates on a trust model
- is widely ignored in implementations

Also network information is not just revealed in Vias but
can also appear in Record-Route, Route, SDP and any SIP 
URLs. (Path header too if this is used by 3GPP).

> In this way, we can identify a network domain via the bordering proxies. Asuming that those proxies do not encrypt the VIA header after adding themself into the VIA header. This can be useful if a…

I think the motivation in 3GPP is more to do with providers 
hiding internal network topography rather than the fact 
signalling ever passed through them.

Cheers,
Neil.
-- 
Ubiquity Software Corporation, UK        http://www.ubiquity.net

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Mon, 26 Feb 2001 09:04:29 -0500

> signalling ever passed through them.

Why hiding the IP addresses or names of servers is of any value has
always baffled me. This strikes me as having no security value, but
making diagnosis of problems that much more difficult. After all, nobody
(except spammers) worries about "exposing the topology of email servers"
and does Received header hiding (I hope...). I think rather than rolling
over and saying "3GPP must know best", some effort at education should
be made by those active in that community. This strikes me as a
requirement where the best approach is to say "you really don't want to
do this" rather than devising ever more ingenious and complicated ways
to pursue the elusive goal of address hiding. If you truly want to hide
the IP address of the end system (for which arguments can be made, as
that address may reveal location information), you'll need some form of
B2B UA, with media handling.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Sean Olson <[email-masked]>
Date: Mon, 26 Feb 2001 09:37:20 -0600

I hope I can clarify this a bit. First, the goal
is not to hide the address of the endpoint. The
goal is to hide the capacity of the core or internal
network. That is, the number of SIP servers in a
given domain. This information is seen as a competitive
advantage in the wireless arena.

In 3GPP, there are essentially three SIP "servers":
A Proxy CSCF (Call Session Control Function) which
sits on the border between the access network and the
core network, the Interrogating CSCF (I-CSCF) that
sits on the border between two operator's network,
and a serving CSCF (S-CSCF) that is the real SIP server
for a subscriber. The goal is to hide the number of
S-CSCFs in an operator's network. To do this, the
I-CSCF is being tasked with this Via: hiding function.

Hope this helps somewhat,
sean

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Mon, 26 Feb 2001 10:45:40 -0500

> I-CSCF is being tasked with this Via: hiding function.

Again, this seems a peculiar notion of sensitive information. Since
adding a server costs 1U and $3k, it doesn't seem like that this is a
good indicator of the number of customers or anything else. Why would
this matter any more than me finding out that AOL has 4 servers for
inbound email:

host -t mx aol.com
aol.com                 MX      15 mailin-01.mx.aol.com
aol.com                 MX      15 mailin-02.mx.aol.com
aol.com                 MX      15 mailin-03.mx.aol.com
aol.com                 MX      15 mailin-04.mx.aol.com

Or that I can analyze a bunch of email messages from AOL and find out
which servers generate my inbound email?

---

From: Sean Olson <[email-masked]>
Date: Mon, 26 Feb 2001 09:39:56 -0600

Via: "hiding" as it is being defined for 3GPP is much different
than the Via: hiding that was in the bis draft. In 3GPP,
we are not asking the next hop to hide our Via: headers
for us. Instead a node is being given the job to hide
the Via: headers of outgoing requests and "un-hide" (
I'm trying to avoid the term decrypt :) the Via: headers
for inbound responses. None of the problems that exist
for the 2543 mechanism of Via: hiding apply in this case.

/sean

---

From: Neil Deason <[email-masked]>
Date: Mon, 26 Feb 2001 16:18:29 +0000

> for the 2543 mechanism of Via: hiding apply in this case.

I would have thought some of them could still apply:
 - prevention of fault diagnosis
 - complexity overhead
 - interference with loop detection 
Isn't there is also still a trust issue of sorts if you 
expect another node to hide your entry in the Via headers
for you. I guess it is too early to say on implementations 
ignoring it ;)

Cheers,
Neil.

---

From: Sean Olson <[email-masked]>
Date: Mon, 26 Feb 2001 10:33:23 -0600

>  - prevention of fault diagnosis

This doesn't prevent the diagnosis of faults.
It isolates the fault diagnosis to the operator
in which the fault occurs.

>  - complexity overhead

There is more complexity involved. Add any
feature and you add complexity. The question
is whether the complexity is worth it.

>  - interference with loop detection 

Loop detection still works fine. Your Via:
will always appear in the clear to you. Complex
looping scenarios between operators may still
cause problems. This is less likely with the
3GPP architecture, but is something to consider.

> for you. I guess it is too early to say on implementations 

There is a trust relationship. This relationship
is well defined in the 3GPP architecture and is
in fact completely internal to a single operator's
network.

The big difference between the 3GPP mechanism and the
mechanism that exists in 2543 is that there is nothing
in the SIP message that is being used to signal to
another SIP server that you wish for it to hide your
Via:'s. There exists a priori a trust relationship
between the two nodes. The hiding of Via:'s is in fact
completely transparent to both inbound traffic and outbound
traffic.

Basically, there is a special purpose proxy that is providing
this functionality. That functionality is guaranteed to be there
by virtue of the architecture -- there is no concern that the
next hop can't provide the necessary hiding functionality.

> Neil.

Cheers!
/sean

---

From: Neil Deason <[email-masked]>
Date: Mon, 26 Feb 2001 16:42:59 +0000

> I-CSCF is being tasked with this Via: hiding function.

From what I have seen of the 3GPP docs it appears there 
could be the potential for a lot of state information being 
stored in these servers. P-CSCFs might be expected to 
maintain mappings of hidden/unhidden Vias, user registrations, 
session signalling paths and even individual call path info 
(when they strip out all Via headers before passing INVITEs 
to called parties)? This type of behaviour means you lose the 
scalability and reliability features for network servers 
that were intended with SIP. Is there not the case for at least
a more DCS-like approach where you at least store state info 
that you really need in the UEs. The revised Record-Route text 
means you wouldn't even need a State header extension. I 
appreciate that there could be issues with storing information 
in the UAs/UEs and retransmitting it over an air interface, 
but if bandwidth is the over riding concern for you SIP is not 
the best protocol to choose in the first place.

Cheers,
Neil

---

From: Neil Deason <[email-masked]>
Date: Mon, 26 Feb 2001 16:50:25 +0000

> is whether the complexity is worth it.

So what is the competitive advantage derived from knowing
how many/few servers in the network? 

I was guessing that the desire to hide network servers
from end points was out of concerns for concealing them
from people like me who might play around with Path or 
pre-loaded Route headers ;)

Cheers,
Neil.

---

From: Sean Olson <[email-masked]>
Date: Mon, 26 Feb 2001 17:18:31 -0600

Neil Deason wrote:

> that were intended with SIP. 

I agree with the principle of favoring stateless
proxies over stateful proxies. But there are cases
where you need to store state in the network. In the
particular 3GPP scenarios you mention, I don't believe
scalability is at risk. Performance, yes, but not
scalability. Reliability is of course an issue. Do
you move reliability into the endpoints or leave it
in the network? You can argue for both cases.

> Is there not the case for at least
> the best protocol to choose in the first place

The problem is exactly as you stated: storing this
information in the terminal and retransmitting it
over the air interface.

Bandwidth is one concern here. Delay is another.
Delay is of course a function of the amount of data
transmitted.

The choice of SIP is now fixed. We are working to
utilize SIP in the best manner possible while
working within the constraints of a wireless network.
This is a challenge, but also a tremendous opportunity
for the SIP community. Given the projected growth of
3G terminals, 3G could potentially do more for the
spread of SIP than anything else to date.

> Neil

Thanks for the comments
/sean

---

From: Michael Thomas <[email-masked]>
Date: Tue, 27 Feb 2001 13:41:25 -0800 (PST)

Sean Olson writes:
 > scalability is at risk. 

   While it's hard to tell whether my hearsay understanding
   of CSCF is screwed up, or whether it's just the 
   general murkiness of all of this, I was under
   the impression that the CSCF was more akin to
   a proxy bolted to a B2BUA.

   If this is still the case, I'd say that both
   scalability, but more importantly *robustness*
   are at issue. Not to mention e2e transparency.

 > Performance, yes, but not

   Sure, but fate sharing is very nice property.
   The CSCF isn't fate shared and that's troubling.

 > working within the constraints of a wireless network.

   I'm having a hard time understanding what
   constraints that the wireless network would
   put on doing this right (ie, the handsets are
   real, not crippled, UA's). I got the impression
   that this was born out of some weird
   assumptions of garden walls, rationalized with
   a helping of "phones too stupid."

		Mike