On Sun, 24 Aug 2003, Karl Auerbach wrote:
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.
Karl brings up many good points here.
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.
A compiler-generated code is going to be more uniform than hand-generated
code. Once you have cleared the compiler output, you can have greater
confidence that its output will be free of security vulnerabilities.
(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.)
I agree that the inefficiencies of compilers have to be improved. And I
think they can be improved. However, I note that the size of SIP libraries
are also becoming quite large. To some extent, the comparision is due to
the greater functionality that is built into the H323 library. I think
that the SIP group underestimated the value of this functionality early
on, and were forced to add it later. Certainly, one of the effects of the
SIP effort has been to validate the utility of this functionality.
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.
Agree.
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.
I respond only that things must be made as simple as possible, and no
simpler.
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.
ASN.1 is not automatically extensible. You have to specify where the
protocol can be extended. If you don't use extensions, it should be
possible to have an ASN.1 runtime that omits the code to handle them. (One
of many possible runtime optimatizations that are possible but rarely seen
in practice, except with hand-coded encoders/decoders)
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.
I think it depends on what kind of overhead it adds to the specification
and the implementations. In an ASN.1, it adds very little, and is of
little concern to the application programmer. However, ASN.1 allows one
to specify fixed length fields wherever it is felt appropriate.
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".
This is how they came into existance, historically. BER existed first,
and there was discovered an ambiguity in the ordering of fields. This
created 2 variants of BER (Basic unordered, and Cannonical ordered). When
PER was created, these same 2 variants (though 'unordered' is the way
listed in the specification--PER doesn't send the tag) were kept, and an
additonal combination of aligned or unaligned were added for a total of 4
variants.
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.
I think a lot of what hurt the ISO/OSI stack was the lack of cheap
commercial ASN.1 compilers. In the beginning, there were no compilers.
One also had to learn ASN.1, and (to start) BER, before one could begin
writing an encoder. By contract, the IETF specifications of concrete
fields and offsets were much easier to start implmementing in C.
I would make an analogy to Graphics: Turtle Graphics are much easier get
started with, but people seem not to use that for "industrial" graphics
applications.
Netmeeting dates from around 1997.
And it still works, due to ASN.1, so long as you can interoperate with a
h323 version 2 client. Pick up a SIP client from several years ago, and
see how far you can get.
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.
Both are equally vulnerable to spoofing. Sometimes I hear people say that
its harder to spoof h323, but in princple, its not any harder if you have
the right tools. If this was ever true, it was mostly the effect of lack
of tools in the past. It has no bearing on the future.
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?
A trustworthy ASN.1 decoder means that someone cannot connect to an H323
system, effect a buffer overflow, and begin listening to what is going on.
The generated decoder stands as a secure interface between the application
programmer, and the intruder. We don't depend so much on the application
programmer to have appropriate knowledge about things like buffer
overflows.
--Dean