Subject: Re: [Sip] Issue #232: TLS v. IPSec

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 27 Dec 2001 11:55:04 -0500

Jari Arkko wrote:

>
>>I think its sensible to separate the transport security into user to proxy
>>and proxy to proxy security. For proxy to proxy, TLS appears much better.
>>
> 
> But here I disagree. There's a few problems in TLS as well. The main
> one from my point of view relates to very large networks (guess which
> ones?) where scalability proxy-to-proxy might be an issue.Here, IPsec
> tunnel mode and separate gateways could help a lot -- if you have an SA
> pair between all operators that is much better than an SA pair between
> each box of each operator (e.g. 1000 operators => 1M SAs; 50 proxy
> farm on each operator site => 2.5 G SAs). 

True, tunnel mode IPSec would reduce the number of SAs. However, as we 
discussed during the 3gpp ad-hoc at IETF 52, there are issues with it. 
Namely, when the IPSec tunnel terminates in front of the proxy, there is 
no easy way for the proxy to know WHICH peer network the message came 
from. To know, it would have to look at the IP address of the source. 
Now, if there are 50 proxies in each operator network, well, you are 
right back to where you started in terms of scale, and the proposed 
benefit of IPSec tunnel mode is lost.

If you don't care about knowing which operator a request comes from, 
then tunnel mode is better. However, note that in this case, the tunnel 
isn't even running on a sip proxy, so the usage of such things would be 
outside the scope of SIP. The ONLY question we need to deal with is ON A 
SIP PROXY, do we say you MUST implement TLS, MAY implement IPSec, or the 
other way around.

> There are also other issues,
> such as the fact that an IPsec tunnel could also be used simultaneously
> for lots of other signaling protection needs 

Same comment as above; of course you can do that, but its outside the 
scope of the spec.

> while the TLS is only useful
> for one thing. SCTP.

SCTP?

> Question: does TLS support preshared symmetric keys (which IPsec does,
> easing deployment as you don't need to deploy certs and possibly PKIs)?

I believe it does not.

> 
> Also, I believe Mike Thomas posted some long list of pros and cons
> for the TLS-IPsec in SIP a while back. Perhaps we could get back to
> that list?

I suspect that the debates will continue without resolution, because I 
think we seem to have different problems in mind. I am concerned about 
cases where the proxy application needs some kind of authenticated 
identity of its peer in order to make policy decisions. Since, 
practically speaking, IPsec is generally done in the O/S, I think TLS is 
better here if that is what you are concerned about. Others want to use 
IPSec gateways, as you have suggested, between operators. Thats fine, 
but its a different problem where clearly IPSec is better than TLS. I 
also think its outside the scope of the spec, as I have pointed out above.

In any case, no one has said MUST NOT use IpSec. Please let us remember 
that. It is only a question of which is mandatory to implement (not the 
same as mandatory to use). The primary issue here is when two proxies 
from different vendors are plopped down next to each other, will they be 
able to communicate securely?

>>It also has a workable keying solution, whereas IPSec does not at
>>this time. 
>>
> 
> I think this is an overly broad claim. They are working on an a new IKE
> version, 

Thats good news, but I am worried about a security solution I can deploy 
this year rather than three years from now.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip