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

Harald Welte laforge@REDACTED
Sat Oct 15 22:45:42 CEST 2011


Hi Kenneth,

I was recently looking into current otp.git, and it seems like this bug
has still not been fixed one way or the other.  I would appreciate if
you could look into a way of permanently resolving this issue.  I'm
happy to work on alternative solutions, if you think the current
proposals (including your one-liner change) are note OK to be applied to
mainline otp.git.

Regards,
	Harald

On Wed, Apr 27, 2011 at 01:52:50PM +0200, Kenneth Lundin wrote:
> 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
> >

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



More information about the erlang-questions mailing list