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

From: Michael Thomas <[email-masked]>
Date: Wed, 2 Jan 2002 14:32:27 -0800 (PST)

So let me add one more data point here. In a fit
of dementia, I hacked up a transport mode only
hmac-md5 ESP-NULL which interoperates with my
Linux box's freeswan IPsec. Total cost in code was
about 6kbytes, and little to nothing in data. 5kb
was the hmac-md5. If you can't afford this, you
can't afford any crypto at all. I don't claim this
is scalable. I claim that it is much better than
nothing though.

What would be the minimal cost for a similarly
stripped down TLS? Can you even run TLS with
manual keys? I didn't think so, but I could be
wrong.

		Mike

Jonathan Rosenberg writes:
 > 
 > 
 > 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

_______________________________________________
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