On Jul 9, 2008, at 12:04 PM, Adam Roach wrote:
Stupid security, on the other hand, isn't something you'll find
anyone who knows the first thing about computers doing. No one uses
stock FTP or telnet for real tasks any more -- it's all scp and ssh.
(Reading this as I just finish FTP'ing files up to a web hosting
provider.) Sadly, I think there's still a great amount of FTP
floating around. Thankfully, though, I'm seeing very little telnet
left.
But ITSPs don't deploy SIP over TLS for reasons I can't fathom.
Anyone who knows the first thing about IP networks recognizes that
it is laughable to authenticate based on source IP address. And yet
ITSPs insist on doing so. The most popular application on the
internet has a well-exercised, certificate-based, crypto-secure
means of determining the identity of a server (TLS). SIP, from its
inception, has been able to leverage this exact mechanism at least
for authentication of servers and for confidentiality of signaling.
ITSPs aren't deploying it.
(Tossing on my VoIP Security Alliance (VOIPSA) hat) So over the past
couple of years I have been asking this exact question of ITSPs with
whom I talk - why aren't you using TLS-encrypted SIP. The answers
almost always come down to:
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?)
2. Ignorance of the security issue. "Well, it's all running mostly
over my own network? What's the real exposure?" (My response - point
them to http://www.voipsa.org/Resources/tools.php )
3. Laziness. "None of our customers are asking for it!" (My
response: "Because they don't realize it's an issue and are trusting
in you to keep them safe. They think it is like the carrier-controlled
walled world of the PSTN.")
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.)
5. Cycles/Staff, aka "We'll get around to it". With especially
smaller ITSPs, I often get an answer of something like "it's on our
roadmap but we just haven't yet gotten around to it". With limited
staff and cycles, they say (understandably) their first issue is
making the system work... and then they'll worry about securing it...
some day... if they make money... if they hire more staff... then
maybe they'll get around to it. (My response - throw up hands in
dismay and go search for a beer.)
The performance argument, especially, is one I have heard repeatedly
for TLS-encrypted SIP. I certainly do understand that there *is* some
degree of a performance hit, but in this era of high-volume and high-
performance SSL-encrypted web sites I find it odd that we can't
leverage that technology into TLS-encrypting SIP sessions.
I think, sadly, that ultimately it will take some kind of "significant
event" where there is a significant information loss or denial of
service for customers to start asking ITSPs for it. Either that or
perhaps some legislation around privacy or something like that.
Given that as a backdrop, I don't see how our defining Yet Another
Security Mechanism is going to make one whit of difference. ITSPs
aren't deploying the stuff we've already done, even the stuff that
is completely ready for prime time and doesn't get in the way of any
business needs.
In my somewhat jaded opinion, ITSPs are going to deploy "the stuff
we've already done" related to SIP security when either:
1. It makes them money.
2. It saves them money. (Really a variant of #1.)
3. It reduces their "risk" in a way they can quantify. (A variant of
#2.)
4. It becomes a market requirement (variant of #1), potentially
because either:
a) a market leader adopts it and the ITSPs start losing sales
for lack of it; or
b) some event happens where they need to for PR/marketing
purposes.
5. It becomes a differentiator in the market place for them to compete
against larger competitors. (Variant of #1, and something I've seen
from a few smaller ITSPs ("We're your source for secure SIP
connections."))
6. It becomes a requirement based on government compliance legislation
or other industry compliance requirements (variant of #1). (Tip: Get
VISA/MasterCard to throw SSL-encrypted SIP into the next iteration of
the Payment Card Industry (PCI) Data Security Standard (DSS) and you'd
wind up with rapid deployment. You can't connect to the VISA/MC
network if your networks don't meet PCI-DSS. If you can't connect,
you can't take credit cards... and we're back to #1.)
My 2 cents,
Dan
--
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO Voxeo Corporation [EMAIL PROTECTED]
Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com
Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com
Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free
_______________________________________________
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
