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

[Kenneth Lundin]

Hi Harald,

For good or bad we have once taken the decision to not introduce
compiler options for
chosing which ASN.1 standard 1990, 1994, 1997 etc. to use. Instead we
try to support all
reasonable constructs from these standards at the same time.

When it comes to the EXTERNAL type we allow input values both as a
5-tuple (1990)
and as a 4-tuple (1994) and use the 5 tuple 1990 format for encoding
as the standard recommends.
When decoding an EXTERNAL type this ends up as a 5-tuple  (1990) as
you describe and
we convert it "back" to a 4-tuple (1994) representation since
otherwise a value using the 1994 4-tuple
format would not yield the same value back when encoded and then
decoded back again.

The problem with this approach is as you also explain that some
information possible present in the
1990 5 -tuple vesion get lost when converted to the 1994 4 -tuple format.

I suggest an easy first step which might be sufficient since the
EXTERNAL type in not recommended to be used at all
any more is to continue with the same conversion upon decode but only
convert to 1994 4-tuple format when this can be done
without information loss i.e. only when the "encoding" component is
{octet-aligned, Octets}.
This will result in that a 4-tuple (1994) or a 5-tuple (1990) value
can be returned from decode and that encode will accept
both of these formats as well.

This will only require a one-liner change in asn1rt_check.erl (plus
the documentation of course)
You can try it if you want.

Just change : in function transform_to_EXTERNAL1994/1

case Encoding of
    {_,Val} ->

to
case Encoding of
    {'octet-aligned',Val} when is_list(Val);is_binary(Val) ->


/Regards 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
>