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

[Kenneth Lundin]

Hi Harald

I agree with you that the current solution is not appropriate if you
decode something encoded as EXTERNAL 1990 and then convert it to 1994 format.
This conversion will loose info and you will not get back the same if
you encode again.

The documentation (users guide) does mention that the decoding always
returns EXTERNAL 1994.

I will look into this.

/Kenneth Erlang/OTP, Ericsson


On Sun, Apr 17, 2011 at 7:54 PM, Harald Welte <laforge@REDACTED> wrote:
> 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)
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>