[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