> 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.
They are not using them because they do not see the benefit of them. The same can be said of ENUM and TRIP, which ITSPs are either ignoring or 'misusing' (from an IETF perspective). The avoidance of RFCs is not at all unique to ITSPs. But it doesn't matter what the ITSPs do inside their networks - we can do this without the ITSP needing to do per-transaction crypto, or TLS, or squat. If it causes them no harm, causes them no grief, and lets them continue Business As Usual, it's a win for them and a win for the edge (their subscribers). We can provide edge-to-edge identity (between enterprises, or handset-to-handset) in both worlds: the world that exists (which has ITSPs with B2BUAs and SBCs) and the world that we hope will exist (RFC3263 routing on the Internet, perhaps with some peer-to-peer sprinkled on top). SIP's current identity mechanism, RFC4474+RFC4916, only works with the latter. I want an identity mechanism that works with both. And I have long been convinced it is possible to build such a beast. -d > ... > > 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
