|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Sausage making, SS7 and protocols
>In a world where the internet industry is becoming >more and more like the telecoms industry, the >necessity of users to have protocol level access >to the network is diminishing, and the dangers >of doing so are becoming greater. Which telcos >will blithely hand out SS7 interconnects to >users? Without (routable) IP access, there >would be no SYN floods of distant networks, no >source spoofing, less hacking, easier traceability, >and the BGP table need only be OTO 1 entry per >non-leaf node on a provider interconnection >graph. Strange how people in the telecom industry think they need to become more like the internet industry, and people in the internet industry think they need to become more like the telecom industry. If you want to see some sausage being made, take a look at the "Advance Intelligent Network" and the Internet interface working group PINT. In the US, with telecom deregulation, the distinction between 'users' and 'telephone companies' is becoming less distinct. When an insurance company, an university, or an ISP files the paperwork to become a CLEC, are they a 'user' or a 'telco?' What telco would refuse SS7 interconnects to a CLEC? The trust model in SS7 makes rlogin look like a high-security protocol. SS7 was developed in an environment where there would be a few trusted 'users.' As the number of 'telco'-like entities explodes, you might see some interesting security issues showing up with SS7. There is some 'screening' between networks, but gateway STP nodes have many of the same problems as Internet firewalls. Internet providers give both less and more access to their networks than telcos. Generally ISPs don't give other ISPs more access to their networks than any other untrusted user. Even read-only SNMP between providers is almost non-existant. Most ISPs would probally consider giving SS7 level access into their network to another ISP a huge security hole. In some sense, interconnecting ISPs is easier than telcos because the security risk of connecting to another ISP is the same as connecting to a user. Today's SS7 network is far more risky than anything Capt. Crunch could do with his whistle. On the other hand, it seems like many ISPs don't consider it a duty to screen or filter their customer's ingress or their own egress. While telco's almost always screen information such as directory numbers when they originate from a customer PBX. This has less to do with the SS7 protocol, than the trust relationship between telcos. Telcos trust other telcos to only send SS7 packets with screened customer phone numbers. This 'trust' is formalized into extremely complicated agreements between telcos, especially who is liable when the trust is broken. ISPs have very simple 'trust' relationships (i.e. trust no one), and correspondingly simple agreements between them. Since there is a much lower trust relationship between ISPs, tracing malicious behavior is much more difficult. At a simple level, look how caller-id information is treated between telcos. Telcos pass caller-id information, more or less, on an end-to-end basis through the SS7 network 'sharing' it with all the telco's along the way. However, telcos don't pass the caller-id information to the 'user' if the presentation-restricted flag is set. ISPs don't normally provide any more information to another ISP than they do to an user. Which model causes less problems when the CLEC turns out to be an private investigative company, or a university. It will be interesting to see which trust model works better as the number of CLECs grows or the number of ISPs shrinks, depending on which consulting group you want to believe. Will ISPs start trusting each other more, or will telcos start trusting each other less? At some companies, the Internet connection is the most secure outside communications connection they have. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation
|