[VOIPSEC] Notes on ASN
Paul E. Jones
paulej at packetizer.com
Sun Jul 29 14:23:23 CDT 2007
Kowsik,
Oh, I've seen the bits on the wire a number of times. On occasion, I've
worked with the binary encoding. But, it's admittedly rare since I do use
tools for 99% of what I do.
Why worry if there are multiple encodings available? Just pick one and use
it. You don't need to use or be an expert at all of them. Packed Encoding
Rules is my favorite, because it does efficiently encode on the wire and it
also removes the need to worry with tags in the syntax for the protocol. If
given good reasons for using another, perhaps I might consider it, but PER
has proven to be a very good choice.
In any case, there are those who love working at the encoding level. Others
do not. I don't like writing bootstrap code for hardware. I also don't
like writing the user interface for applications. I like working somewhere
in the middle of the stack. But, there are others who love UI design and
are damn good at it. The way I view it, the world benefits from the fact
that there are those who like to work on different aspects of any software
application or hardware platform.
I guess I don't understand your rant. If you don't like efficient binary
encoding work, find something else to work on.
Paul
> -----Original Message-----
> From: Kowsik [mailto:kowsik at gmail.com]
> Sent: Saturday, July 28, 2007 3:29 AM
> To: Paul E. Jones
> Cc: Voipsec at voipsa.org
> Subject: Re: [VOIPSEC] Notes on ASN
>
> 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
> > >
> >
> >
> >
>
More information about the Voipsec
mailing list