Signalling System No 7
en.wikipedia.org
en.wikipedia.org
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.
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...
- 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...
> 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 ;)
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 :-)
Supposedly this happened because the other telco had hired a pentester...
Edit: Maybe 100% is too rigid, but you get the idea. ;)
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.