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.
Part of the issue might be a variant of 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?
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.
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...
> - 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 ;)
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 :-)
> 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...
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.
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.
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.