[erlang-questions] asn1ct/asn1rt EXTERNAL 1990/1994 conversion information loss

[Harald Welte]

Hi!

I'm working on a variety of (Free Software) projects related to mobile
communications (http://cgit.osmocom.org/).  One of them is dealing with the GSM
MAP protocol (TS 09.02, TS 29.002) which is specified in ASN.1

I'm using the Erlang asn1ct/asn1rt to parse incoming MAP messages from the
worldwide SS7 backbone, filtering + patching some of the data contained in
it and re-transmit the MAP messages.  It's like an application-level-gateway /
proxy that can modify some of the data.

MAP itself uses TCAP (Q.773).  TCAP messages have a dialogue and a component
portion.  The dialogue portion is specified as an EXTERNAL type:

DialoguePortion ::= [APPLICATION 11] EXPLICIT EXTERNAL

Note: The MAP sender are (normally?) using the 1990 representation of EXTERNAL,
not the 1994 version.

Erlangs asn1ct-generated dec_EXTERNAL code first internally generates along those
lines:

#'EXTERNAL'{
            'direct-reference' = {0,0,17,773,1,1,1},
            'indirect-reference' = asn1_NOVALUE,
            'data-value-descriptor' = asn1_NOVALUE,
            encoding = 
                {'single-ASN1-type',
                    [96,15,128,2,7,128,161,9,6,7,4,0,0,1,0,1,3]}}

However, the asn1ct generated code automatically converts this #'EXTERNAL'{}
record into a tuple of the following structure (using
transform_to_EXTERNAL1994/1):

{'EXTERNAL', {syntax,{0,0,17,773,1,1,1}},
             asn1_NOVALUE,
             [96,15,128,2,7,128,161,9,6,7,4,0,0,1,0,1,3]}

The problem is, when you pass this tuple into the asn1ct-generated encoder,
the 'single-ASN1-type' information has been lost, and it will be replaced with
'octet-aligned'.

The result is that instead of {tag,'CONTEXT',0,'EXPLICIT',32} we now use
{tag,'CONTEXT',1,'IMPLICIT',0} for encoding the data.  This is not valid within
the scope of MAP, and both the wireshark MAP dissector as well as all MAP
implementations I've seen reject or ignore the resulting message.

The problem fundamentally can be summarized as:
* EXTERNAL can contain inner data in either 'Single-ASN1-type' or
  'octet-aligned'
* the OTP asn1ct (at least in ber_bin mode) looses this information and
  does not pass it back to the caller when decoding
* if the resulting data is passed through the encoder, the encoded data
  semantically differs from the original undecoded BER data.

I think this is probably not the intended behaviour.  It would be weird if
decoding and re-encoding the same unmodified data leads to different BER tags
in the tree.

What is wrong in passing the 1990 or 1994 EXTERNAL types from the decoder into
the user program?  Why should the user not know which of the two formats was
being used?  I believe at the very least, this automatic conversion should be
something that can be configured as a compiler option.

Any comments/ideas/suggestions?

Regards,
	Harald
-- 
- Harald Welte <laforge@REDACTED>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)