Dan York wrote: > 1. Performance. "TLS-encrypted SIP is great in theory but when you > are terminating 10,000 simultaneous SIP connections there is too much > overhead." (My typical response: Can't you get hardware SSL > accelerators? Or, gee, giant websites can do SSL for HTTP, are SIP > connections really that much different?)
Yes, a bit. For one, HTTPS works fine as long as the server has a certificate. SIP can do so as well, but for TLS connections between two proxies, both of which have certificates, the mutual authentication problem is rather new in SIP. Second, the temporal nature of a TLS connection is different in SIP than in HTTPS. In the latter, clients typically establish many simultaneous connections to pipeline downloads and then promptly close them (unless keep-alive is negotiated. Even if keep-alive is negotiated, the life of a HTTP transaction is shorter than a SIP transaction, so closing the TLS connection is a perfectly good thing to do when a client is done accessing the resource in HTTPS.) Third, the whole notion of upgrading/downgrading URIs does not exist in HTTP, so when you see a https:// scheme, you know that it is TLS from client to origin server, even in the presence of HTTP proxies. Fourth, even in the presence of HTTP proxies, the certificate displayed to the client is that of the origin server, which is not the case in SIP's hop-by-hop TLS model, which has lead to its own set of problems amply documented else- where. And finally, in HTTP there is only one transport: TCP. So TLS-over-TCP accelerators became commodity items. In SIP, with the multiple transports to support and the fact that TLS can run on top of all of them makes it hard to get accelerators that support multiple transports (maybe EKR or someone else can correct me here, but I don't think there are dtls accelerators in use today -- I am not sure whether a TLS-over-TCP accelerator's firm- ware can be used to support TLS-over-UDP without any modifications. Even OpenSSL had to be modified to support dtls at the TLS record layer, so I would assume that any existing TLS accelerator would have to be so retrofitted.) > 4. Ignorance of the state of the standards/technology. "Well, the > IETF is still defining all of that." (My response is to point out > that media encryption and SRTP key exchange may be still evolving but > TLS/SIP is well understood.) Media encryption and SRTP key exchange have stabilized of late, as have some TLS-specific concerns in SIP through various drafts like sip-sips and domain-certs, sec-flows, etc. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: [EMAIL PROTECTED],bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
