
Signalling System No 7 - godelmachine
https://en.wikipedia.org/wiki/Signalling_System_No._7
======
kpil
While a bit unergonomic to work with, the .7 protocols uses ASN.1 for defining
and describing a lot of the protocols and messages.

ASN.1 have some nice ideas that the developer community has failed to grok,
reverting back to simpler ideas that are more immediately rewarding, such as
hand coding a lot of code that blasts away text based messages that may or may
not be understandable to the recipients because, hey it works on my machine.

The core idea is that there is a language that defines the abstract message
content, and there can be several encoders - binary, text, compact binary,
depening on needs and computing and bandwidth requirements.

There are also some support for defining the criticality of any extensions to
a protocol, to inform recipients if the can disregard an additional part it
does not understand or if it's critical.

This is not an afterthough as json schema, but the core idea.

~~~
cesarb
Part of the issue might be a variant of FUTON bias
([https://en.wikipedia.org/wiki/FUTON_bias](https://en.wikipedia.org/wiki/FUTON_bias)):
can I easily get the official text of the ASN.1 standard, without having to
register somewhere and/or pay hundreds of Euros?

~~~
kpil
I think it specifically is not used because it's a more complex idea that
requires a lot of initial effort and mental work until the benefits are
apparent.

I guess it's just like most other "actually better than x" languages and
standards out there.

In this case it's also not the nicest language to read and it's a bit dated.

It would be nice with an ASN.2 though...

~~~
lttlrck
The idea is similar to protocol buffers. Tooling is a significant barrier to
entry.

\- The commercial offerings are very expensive.

\- it is a little hard to read, but very difficult to write correctly.

\- it is difficult to parse the spec and code generation is non-trivial, and
although Basic Encoding Rules are relatively straightforward, Packed Encoding
Rules are not. So rolling your own is daunting.

\- There are some open source tools but until recently they were unable to
parse the latest language features used in LTE. I am convinced it is designed
to be hard to parse to protect the encumbents.

\- Unless you are using C/C++ (most tools generate these) you have to somehow
generate FFI bindings, which you’ll want to automate for a large spec which
requires parsing the spec...

~~~
yaantc
> \- There are some open source tools but until recently they were unable to
> parse the latest

> language features used in LTE.

> I am convinced it is designed to be hard to parse to protect the encumbents

I don't think so, and I work for a small company doing LTE products. LTE uses
a rather small subset of ASN.1, and it's not a big problem to handle it
really. It's not a barrier at all, it's even making things simpler compared to
a less formal definition of protocol messages. I experienced informal
protocols, with the result of wasting a lot of energy on interoperability
tests due to different interpretations. ASN.1 in LTE gets rid of this.

IIRC, ASN.1 was created as a specification language written by humans for
humans. Only later on it became used for direct code generation. So its design
was not meant to be easy to parse for a compiler, although it's the way it's
used now.

There are several reasons to the lack of open source tools IMHO. A full ASN.1
compiler is a complex project, so that's some barrier to entry: not everyone
can invest the needed time. The fact that any application typically need only
a subset of the full ASN.1 means that there's likely a lot of partial /ad-hoc
implementations, so not very fit to open source. Then there is a cultural
aspect leading to a lack of interest: ASN.1 is old and from a specific, non
mainstream culture (the telco world). The new kids are just busy with JSON or
protocol buffer, even if ASN.1 works very well. It's software, we're all busy
re-inventing our own better wheel ;)

~~~
lttlrck
I didn’t mean to say LTE is deliberately complex, compared to older specs it’s
very simple. I was thinking more of ASN.1 itself which even in later editions
added features that only made the parsing and codegen harder, though they made
authoring simpler.

Specifically I was looking asn1c but IIRC it could not handle parameterization
used in S1AP - maybe 3 years ago? It might have changed right after I tried, I
didn’t follow it up and took a different route.

I think we agree, the problem is worsened when you need to support multiple
ASN.1 protocols, including MEGACO, S1AP, RANAP, H.323, GSM MAP, TCAP etc - you
need a tool that provides a stable and unified API for all protocols. And if
you want that, today you still have to pay for it or struggle with multiple
tools with different APIs.

Don’t get me wrong I like ASN.1 _very_ much. Text based protocols (esp. over
TCP) have caused me more headaches than ASN.1 and ad-hoc binaries protocols
combined. HTTP/2 is worth it just for ditching text. The rest of it is just
icing :-)

------
digi_owl
> In February 2016, 30% of the network of the largest mobile operator in
> Norway, Telenor, became unstable due to "Unusual SS7 signaling from another
> European operator".

Supposedly this happened because the other telco had hired a pentester...

~~~
Rjevski
Yep. I can confirm.

~~~
ianai
And that’s how you get lawsuits.

------
myrandomcomment
Built before the idea of bad actors was a thing..

~~~
wolrah
Most certainly not. One of the purposes of the move to out-of-band signaling
was to stop the various "box" attacks on the tone-based in-band signaling used
previously.

They were very aware of bad actors, they just assumed that their private
signaling network would remain private and thus any bad actors with access
would be easy to identify and deal with. They never imagined the situation we
have today with tens of thousands of telephone service providers and even
large customers of those having direct access to the signaling network.

~~~
myrandomcomment
Let me try again. Built before bad actors that were the state, or someone
smarter then hackers on the outside, were a thing. SS7 once you are on net
with it is pretty wide open.

------
kikoreis
Sadly heralding the end to an incredible run of blue boxing..

~~~
kokey
Fortunately it took a while for ss7 to be adopted on all international trunks.

