Sausage making, SS7 and protocols

Sean Donelan SEAN at SDG.DRA.COM
Tue Nov 4 13:12:27 UTC 1997

>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

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

More information about the NANOG mailing list