[VOIPSEC] Notes on ASN

[Kowsik]

Paul,
Appreciate your 20,000 ft view of ASN. My rant wasn't about the
complexity of the ASN language itself. I completely agree with you on
the effectiveness of ASN, if and only if you interact with it
predominantly through tools where you never to get see the bits on the
wire. Having a strongly typed data model with a strict grammar
definitely adds determinism on both the sender and the receiver. I'm
all for code generation.

Unfortunately, most of my adventures and encounters with ASN have
repeatedly been under the hood, so to speak. The number of rules and
exceptions to the rules during the encoding/decoding is really mind
boggling. I'm sure there are profound reasons (and if I think hard
enough about it, it does make sense) for creating these rules, but the
sheer size of the choice space makes it incredibly complex.

K.

On 7/26/07, Paul E. Jones <paulej at packetizer.com> wrote:
> Kowsik,
>
> I'm neither the author of ASN.1 nor a contributor to the work, but I've used
> it quite a bit.  While there are a lot of options for encoding, nobody is
> required to be an expert in all binary or ASCII encoding rules.  Nearly
> every project in which I use ASN.1 uses PER.  (And, no, PER does not mean
> you're on dial-up.  For the same reasons that we have RTP header
> compression, SIP signaling compression, e-mail ZIP files, etc., bits on the
> wire still often matter.)
>
> From the user's perspective, ASN.1 is not hard.  You define a syntax,
> compile it, and then use libraries to encode and decode messages.  I can
> create or modify a protocol, re-compile, and have it encoding/decoding in
> minutes.  Further, ASN.1 fully supports older versions of the protocol
> through the use of extension markers (...) in the protocol definition.  So,
> I can send a newer PDU to an older system and it is properly handled.
>
> Compare that to other protocols: how you handle backward compatibility is
> entirely dependent on how you define your own way of addressing backward
> compatibility.  Nearly every non-ASN.1 system has its own unique way of
> extending the protocol for future revision.  Now, that is ugly.
>
> Complexity is entirely relative and often a matter of perspective.  Very few
> systems are "simple" if they actually do anything useful.  Even if the user
> interface is simple, it does not mean the underlying software to support the
> user is not.  The complexity in the ASN.1 specs might be a good example:
> there are great tools out there that handle all of the complexity for me so
> that I can get my job done.  From the user perspective, I view ASN.1 to be
> very simple.
>
> Paul
>
> > -----Original Message-----
> > From: voipsec-bounces at voipsa.org [mailto:voipsec-bounces at voipsa.org] On
> > Behalf Of Kowsik
> > Sent: Thursday, July 26, 2007 12:57 AM
> > To: Voipsec at voipsa.org
> > Subject: [VOIPSEC] Notes on ASN
> >
> > More relevant here than anywhere else. I'm just amazed at how we've
> > embraced complexity of systems that we really ought to be simplifying.
> >
> > http://labs.musecurity.com/2007/07/25/asn-as-in-hell/
> >
> > K.
> > ---
> > CTO, Mu Security
> > http:///www.musecurity.com
> > http://labs.musecurity.com
> >
> > _______________________________________________
> > Voipsec mailing list
> > Voipsec at voipsa.org
> > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> >
>
>
>