On 7/9/08 10:31 AM, Dan Wing wrote:
Yikes. That's not a circus -- that's a abattoir. It's a very careful
analysis of why carriers want all of SIP except for the SIP part.
It looks like it boils down to:
4.1.1(a) - Some SIP products are broken by either design or
implementation
4.1.1(b) - Inter-service provider federation is being rolled out
without any of the tools the IETF has defined for that
kind of thing
4.2 - Service providers won't deploy DNS, despite it
being integral
to SIP and the Internet at large
4.3 - (Mostly a symptom of 4.2) People are deploying security
theater without any of the tools the IETF has defined for
that kind
of thing, and tel: URLs aren't apparently supported, even
when E.164
is the only useful identifier in use. (If you can change
the domain
of a URI and still have it mean anything at all, it
should have been
a tel: URL anyway)
4.4 - This isn't a stand-alone issue; it's a symptom of 4.1.1(b)
In short -- if we ignore the software bugs, it looks like the
problems all boil down the service providers choosing to ignore
various IETF-defined solutions (mostly as they relate to security).
By IETF-defined security solutions, are you referring to Speermint,
which is all about SBE and DBEs?
No; I mean solutions like mutual TLS for domain authentication. Or even
IPSec gateways, like 3GPP has defined. There are secure ways to do what
service providers want to do. But, for some reason, the idea that you
can secure networks by whitelisting based on unverified "From" header
fields has gained mindshare. For some reason, people are still
authenticating based on source IP address (!!!) instead of using any of
a myriad of certificate-based techniques. I mean solutions like RFC 3263
for machine location instead of using point
codes^H^H^H^H^H^H^H^H^H^H^HIP addresses.
...
There are similarities between the 'Service Providers are
destroying SIP' argument and the 'NATs are destroying the
end-to-end Internet' arguments popular in the IETF during the
1990's. NATs were (and are) deployed because they met a need.
The abuse of SIP is being done to meet a need -- it is not being
done to upset the digerati.
I don't think the situations are fully comparable. I understand the
problems NATs were introduced to solve. You'd have a hard time finding
anyone in the IETF who doesn't operate at least one NAT of their own.
It's a sad little secret that we hate them from a protocol design
perspective, but embrace them for our day-to-day tasks.
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. 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.
The problem isn't a lack of available solutions for these kinds of
problems -- it's the fact the ITSPs are employing the same kind of
moronic "security" that gave rise to blue-boxing in the 1970s. I don't
claim that it's being done to upset us; the reasons aren't exactly
clear. They could be ignorance. The could be intransigence. They could
be plain stupidity. But there's something there that's preventing the
adoption of any real IETF-defined security by ITSPs.
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. How will this effort be different?
/a
_______________________________________________
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
