Subject: RE: [Sip-security] Basic/digest over TLS

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 23 Oct 2001 23:20:51 -0400

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:[email-masked]]
> Sent: Tuesday, October 23, 2001 3:49 PM
> To: C. R. Kalmanek
> Cc: Jonathan Rosenberg; [email-masked]
> Subject: Re: [Sip-security] Basic/digest over TLS
> 
> 
> "C. R. Kalmanek" wrote:
> > 
> 
> > Assuming TLS connections are long-lived, how scalable is this
> > solution?  Web servers have not had to deal with persistent
> > connections that last essentially forever, from huge numbers
> > of clients.  Scalability may not be an issue in the short
> > term, but we need to take a longer view.
> 
> Would the session lifetimes be much longer than, say, for a 
> web banking
> or order application, where it's probably also on the order of minutes
> to tens of minutes? 

I suspect you are going to need to keep them open indefinitely to support
quick call setups. In any case, proxy->UA tcp connections are not likely to
work for nat/fw reasons.

> 
> > 
> > Can TLS connections be initiated from server->client? (so we
> > don't need to keep them around forever).  If so, what is the
> > impact on session establishment delay?
> 
> I'm not sure, but according to Thomas, "SSL and TLS Essentials", the
> (TCP, I assume) server can ask a client to restart the connection
> (Section 4.5.1), using HelloRequest.

Does having a different tcp directionality (compared to the client/server
tls roles) introduce any security issues?

> 
> Also, this seems to be primarily a memory issue. Anybody know how much
> state is consumed by a TLS connection, above and beyond TCP 
> state? If we
> assume 1 kB and 20,000 connections, which seems high for a single
> server, that's 20 MB, which costs roughly $3.

The issue about memory/resource consumption for lots of tcp connections
plagued the IMPP working group for months. Seems that there is a lot of very
contradictory anecdotal evidence about this subject. 

-Jonathan R.

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

_______________________________________________
Sip-security mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/sip-security

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 23 Oct 2001 23:23:55 -0400

> quick call setups. In any case, proxy->UA tcp connections are not likely to

Not all environments run firewalls or, more seriously, NATs,
fortunately. For example, I could well see running this inside a
corporation, to the outbound proxy.

> tls roles) introduce any security issues?

Not that I know of. From my limited understanding, this simply is a
request to the client to start the normal TLS handshake, so the rest of
the TLS exchange is exactly the same.

> contradictory anecdotal evidence about this subject.

I suspect that the answer will largely come down to OS written for web
servers (NT, Solaris, Linux) vs. real-time OS (VxWorks and kin). The
primary problem is not likely to be memory consumption, but search time
for connection lookup.

---

From: "Jari Arkko" <[email-masked]>
Date: Wed, 24 Oct 2001 08:03:55 +0300

> quick call setups.

Keeping the session open indefinitely would cause an interesting situation
in the mobile networks where local proxies are contacted by roaming
terminals: the proxies would be keeping state not just with everyone who
is on the area but also those who have been on the area. Does your OS
support a billion open TCP sessions?  ;-)

The TLS solution is excellent in many respects, but I do have a number
of concerns particularly with its application on large mobile networks.
Perhaps someone can answer my questions below:

* Unnecessary reliance on public key crypto. There's never enough CPU
  and power on small mobile devices (if there was, the manufacturer would
  make the device smaller and the battery to last longer). Are we taking
  public key crypto because we need it, or because our symmetric key
  protocols aren't good enough?

* Bandwidth. How much extra bandwidth is going to be consumed by sending
  certificates etc?

* Roundtrips. I don't know how many additional roundtrips TLS introduces, but
   it is essential to minimize them, in order to get the call setup and/or registration
   delays small. IKE at least introduces currently too many roundtrips for this
   application (in the order of 9 messages). RTT is *long* in cellular networks.

   Given the roaming situation, delays in registration/initial set up are also
   relevant, particularly when radio resources are consumed and there is
   no guarantee yet that the subscriber makes any billable traffic.

  So, what is the additional amount of RTTs introduced by TCP + TLS?

* Can we reuse legacy authentication schemes in TLS? This would be
   important for e.g. 3g folks who would like to reuse existing infra (smart
   cards, procedures to hand out them, slots in devices, etc.).

* Even if we were able to make TLS perfect in this environment, we still
   face the problem that it is hop-by-hop. In many cases I see that an
   end-to-end solution is needed as well, so wouldn't we prefer a solution that
   can handle both the hop-by-hop and end-to-end protection cases?

That being said, I think both TLS and IPsec/IKE are clearly the preferred
solutions in many cases, e.g. protecting traffic between proxies or within
a corporate LAN.

Jari