Subject: RE: [SIP] VIA header encryption?

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 28 Feb 2001 09:18:14 -0500

> -----Original Message-----
> From: Sean Olson [mailto:[email-masked]]
> Sent: Monday, February 26, 2001 6:19 PM
> To: Neil Deason
> Cc: [email-masked]
> Subject: Re: [SIP] VIA header encryption?
> 
> 
> > 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
> 
> 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 conversation on this thread has been moving between several different
via header issues. It was my understanding that via mucking was happening in
two places:

1. P-CSCF removes via, RR before sending an INVITE to a called party, to
save bits on the air. This requires transaction stateful proxies to restore
the information in the response. No call-statefulness required.

2. I-CSCF will encrypt the via headers, and record-routes, to avoid exposing
the information outside the network.

Please note that via hiding was removed from the spec primarily because of a
security issue. The element that wanted the encryption needed to ask the
next hop, possibly in a different domain, to perform it. Encryption and
hiding can still be done in a number of ways, none of which require
standardization. Some of them can be done statelessly.

The issue with bandwidth has to do only with the P-CSCF removal of via and
RR headers.

Henning writes:
> 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?

I've seen this requirement for hiding from wireline providers as well - not
because the number of servers is sensitive information to be hidden from
competitors - but because of hackers. The primary issue, in my mind, is
allowing outside parties to learn the IP address of servers within the
network. Once that happens, lots of tools are at their disposal to attack
these machines. Given that phone companies have historically been a favorite
attack point for hackers, and given that these attacks are much easier when
we are talking voip, I think paranoia is a good thing here. 

Sean wrote:
> 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.

That depends entirely on the implementation.

Any hiding mechanism that is transaction stateful will suffer from
robustness problems, and call stateful mechanisms will be even worse. If
done statelessly (which is possible), you get the robustness benefits
stateless proxies can offer. 

I think loop detection is generally going to suffer. A complex
implementation might look for a spiraled request, and when it sees one,
attempt to locate/decrypt the hidden headers to look for a loop. That may or
may not be possible depending on how the hiding is implemented.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 28 Feb 2001 09:20:37 -0500

> we are talking voip, I think paranoia is a good thing here.

These providers should be informed that they are clueless :-) There are
port scanners around that search millions of IP addresses very quickly,
automatically and without the hacker lifting a finger. Thus, this offers
almost no protection, except assuring PHBs that "yes, we're hiding our
network".

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

---

From: Neil Deason <[email-masked]>
Date: Wed, 28 Feb 2001 14:53:47 +0000

> the information in the response. No call-statefulness required.

True, the 3GPP expectation for the P-CSCF being call stateful 
must come from elsewhere. I'ld like to learn more about exactly
why this is thought to be needed, it is definitely in the docs.

There is the idea of storing state in the P-CSCF for things 
like return-call service to caller-id blocked calls. Although 
caller-id blocking is another can of worms without using a 
B2BUA as an anonymizer.

> we are talking voip, I think paranoia is a good thing here.

The trusted next hop was one of the security issues that lead 
to the deprecation of Via hiding. But another was just false 
impression of security doing this could create for the naive as
hiding a box's IP doesn't make it secure. After all old style 
Via hiding could have 'worked' within a single providers 
network where the servers could trust each other.
 
> may not be possible depending on how the hiding is implemented.

Yeah that bothers me with the potential for complex service 
based routing in the future. I remember the time when our proxy 
had to look through Via headers figuring out if it could 
decrypt any before doing loop detection. Not pretty.

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