It has been my experience that ASN.1, no matter which encoding rules are
used, has proven to be a failure and lingering interoperability and
denial-of-service disaster.
I think the nugget of our discussion is the old, and probably
unanswerable, question of what is the proper balance between present
function and future (unforeseen) extension.
Back in the 1970's I met a very smart system designer. He drew a
distinction between "intricate" and "complicated". A fine watch with many
moving parts could be intricate as being a well engineered solution to a
specific problem, while a Rube Goldberg timepiece could be complicated and
not well engineered. The difference being the fact that unnecessary
elements are elided from an intricate solution unless there is a specific
articulated reason to leave them in.
ASN.1 (along with other general purpose encoders such as XML) carry a
heavy burden of machinery that is present whether it is needed or used or
not.
Your point about ASN.1/PER having some security benefits because the
cleartext is less predictable is interesting - and I sense that it is
quite valid. However I would suggest that there is a much greater risk
that comes from putting the heavy and complex machinery of ASN.1/*ER
engines into deployed implemtations - and that is that most
implementations of products are very poorly tested against any but the
most mainstream of traffic flows. A complicated engine such as ASN.1/*ER
is full of nooks and crannies where undetected flaws could exist.
A simple encoding, well suited to the particular job at hand, is less
likely to contain untested code paths, whether those paths be generated by
compiler or by hand.
(By-the-way, I don't accept the assertion that compiler generated
ASN.1/*ER engines are going to be better than hand tooled ones - most of
the latter that I've seen (some of which I've written) use libraries for
all the heavy lifting - fix a bug in the library and relink and you're
done, just like with a compiler. And I agree with Rob A. that in many
embedded devices, we still can't ignore memory and processing
inefficiencies.)
The net is slowly evolving an edge layer of devices that are best
described as sealed appliances - these are small devices that will tend to
never experience an update to the factory installed code image. It is far
more important to get these right before they are shipped than to have the
ability to extend their capabilities in the field.
I do not believe that complicated representations such as ASN.1/*ER
reflect a good balance between engineering needs for the present and
expansibility for the future - thus I put ASN.1 and *ER into the
"complicated" rather than the "intricate" category.
It is certainly true that net telephony and conferencing need
extensibility - but I would suggest that the hooks for extensibility ought
to be concisely defined and placed in specific parts of the protocol
structures (such as the SDP part of today's call establishment protocols).
I see no need to burden the entire protocol representation under a mutable
layer of complexity such as ASN.1 when there is no reason that can be
articulated to require such mutability.
By way of analogy: IPv6 addresses could have been of variable size, like
NSAPs. But so far I don't think that enough reasons have been put forth
to justify moving away from a relatively solid and fixed-size format to a
variable address format.
Good engineering includes a kinda sixth sense of knowing when to stop
adding features.
And of course, the protocol specifier is free to specify one of 4 variants
of PER....
When I see phrases like "4 variants" I hear "one normal way and three
routes for attack". Which reminds of of why the Internet isn't running
ISO/OSI today. (Although I was surprised to learn recently that the ICAO
is presently mandating voice over CLNP for some new ground-air and air-air
systems for commercial airplanes.)
ISO/OSI had lots of good ideas. But it could never focus or prune. It
built a top heavy, over-optioned Vasa[*] that tipped over and sank before
it could ever be deployed.
[* - The Vasa was a 17th century Swedish warship that was so larded with
options that it tipped over and sank on its first trip across the harbor.]
I really want VOIP and conferencing to work, not sink.
As far as SIP vs H.323 goes - apart from the market fact that it is
getting increasingly more difficult to find new products that support
H.323 -
Few products? Every Microsoft OS ships with an h323 client called
netmeeting.
Netmeeting dates from around 1997.
Most of my hard VOIP phones are either SCCP (let's not talk about that ;-)
and/or SIP. I haven't heard much "buzz" about new H.323 work.
I find just the opposite. Now I have to worry about the security of SIP
phones, and that they might be used for evesdropping. H323 and and
trusted ASN.1 compilers can go a long way past SIP for ensuring
trustability of such devices.
You are not alone in your concerns about security. I too am concerned
about spoofing of SIP messages but I haven't gotten my hands dirty enough
with SIP at that level to know whether I'm just being paranoid or whether
there is really some substance to my concern.
However, I don't see how an ASN.1 compiler adds or subtracts anything from
the tap-ability, legal or not, of a VOIP conversation. What am I not
seeing?
(Let's not go off into the infinite set of painful issues surrounding
things like CALEA.)
--karl--