Subject: Pretty clear ... SIP

From: [email-masked] (Dan Kolis)
Date: Thu, 21 Aug 2003 14:35:28 -0400

Since SIP is IETF not ITU its only reasonable to have internet believers
lean towards it.

H.323 ? Ahhh no thanks.

No serious look at these can even consider H.323 etc and its derivitives as
useful in the general case. The only reason they were used is the absence of
a better alternative.

Try to hook your Sony Playstation up through H.323

When would that move through committee? Spring of 2010 ??

Oh. Another reason for IETF to believe in it is that its basically a free
comm technology. H.323 wants to drag in the old timers and their costs
structures... dependance of geography, etc so there is a credible reason by
most criterea.

Regs,
Dan

---

From: S Woodside <[email-masked]>
Date: Sat, 23 Aug 2003 13:43:36 -0400

The difference between internet telephony and voice chat.

This is fairly critical actually. It doesn't matter if you're talking 
about H323 or SIP although obviously there is a bias in each one 
towards one or the other. The commonly used VoIP name does NOT do 
enough to differentiate, we need to be talking about IP telephony and 
voice chat as two DIFFERENT beasts since they have substantially 
different expectations of availability!

People expect a telephony system to be available even if the power goes 
down, virtually all the time, how many nines of availability? Lots. 
More than the internet actually. In fact, they would basically expect 
IPtel systems to keep working even if the internet goes down. They 
reach for the IP phone, a physical object on their desk, most likely. 
This is not really "internet" stuff this is the adaptation of internet 
protocol to telephony fields where internet availability doesn't cut it.

On the other hand, voice chat is also VoIP but the expectation are 
completely different. People basically expect it will operate through 
the computer. It will only work if the internet connection is working. 
Power failure ? goodbye. This is not a telephone replacement. It's a 
supplement. It's going to be dirt cheap and have all the other goodness 
that typically characterizes internet technology.

simon

--
      anti-spam: do not post this address publicly
www.simonwoodside.com -- 99% Devil, 1% Angel

---

From: Dean Anderson <[email-masked]>
Date: Sat, 23 Aug 2003 20:40:09 -0400 (EDT)

Err, I think there are some things missing:

1) H.323 closely matches PSTN protocols and capabilities. Its
interoperability with ISDN and SS7 are far more natural.

2) H.323 is more efficiently coded using ASN.1.  One might not think that
this matters, but in fact it matters a great deal in large volumes.
H.323 is PER encoded, which frequently results in about 50% compression
over uncompressed data. Smaller packets have lower latency, and take less
time to transmit. Advances in processor speed over IO speed has made
compression almost a zero cost feature.

3) Standardization is _way_ better with H.323.  The IETF process relies on
the standard-writers to do the implementations, which we then hope are
well documented in the standard. They aren't always so well documented. So
long as the group of implementers is small, this isn't a problem. But in
large groups, it doesn't work very well. Such an iterative process of
implementation/documentation/implementation is slower than complete
specification -> implementation except when the group of implementers and
documenters are small, so that undocumented or vague parts can be passed
informally amoung the implementers.  For example, consider that the DNS
groups have been struggling for years with ambiguities in RFC 1035.
Things still aren't fully specified, and there is a great deal of
difference and incompatibility between Bind 9 implementation and other DNS
implementations.  It doesn't seem that these ambiguities will be resolved
soon.

4) H.323 has free infrastructure: There are free ASN.1 compilers (I'm even
am about to release one). There are free implementation of H.323 protocol
stacks, and free h.323 software.

5) H.323 moved through 4 major well defined enhancements far faster than
SIP.

6) SIP started out saying that it could do the job simpler and easier than
H.323. So far, this hasn't proven to be the case. SIP is now just as
complicated as H.323. The reason for the complication is driven mostly by
the PSTN, and the features that you find on phones and PBX's. These
features haven't changed, so the complexity is still the same.

However, this is not to say the SIP effort was wasted. Not in the least.
There has been a tremendous amount of productive feedback and cross
pollenation between the two groups. There is nothing like competiton to
make one think pragmatically.  SIP significantly influenced the attention
to performance in H.323 after version 1, and resulted in features like
FastStart and other procedures to reduce the startup traffic. There are
probably other examples of productive feedback between the two.

H.323 and ASN.1 eventually surpass a text based protocol because they are
better specified and can be implemented by compiler, securely, and
compatibily.  A compiler handles more of the compatibility between
different implementations. Text based protocols are by definition vague.
Handwritten parsers offer more opportunities for bugs, incompatibilities,
and security problems.  ASN.1 has other advantages that I won't go into
here.

The most pointed past disadvantage of ASN.1 was that it was complicated
and expensive, because there were no free compilers, and decoders were
also hard to come by. That has all changed. Etherreal and other free
packet analyzers have H.323 modules, and can now easily incorporate other
ASN.1 based protocols.  Recent enhancements to ASN.1 allows for
specification of encoder rules so protocols like IP or Q.931 can be
specified and implemented by compiler. There is really no reason for the
IETF not to consider using ASN.1 for protocol specification, and in fact,
it does in the GSSAPI.

		--Dean

---

From: Karl Auerbach <[email-masked]>
Date: Sat, 23 Aug 2003 19:03:30 -0700 (PDT)

On Sat, 23 Aug 2003, Dean Anderson wrote:

> H.323 and ASN.1 eventually surpass ...

Ummm, based on my own direct experience with ASN.1 since the mid 1980's
(X.400, SNMP, CMIP...), I disagree.

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.

For example, the flaws in ASN.1 parsers in SNMP engines have proven to be
a decades+ old vulnerability for the net.

We'd be much better off with XML, Scheme expressions, or Python pickles
than with ASN.1 both for expressing data structures in documents and for 
encoding data structures into binary for carriage in packets.

If one wants compression, then it is better to apply it to the entire
packet, or the byte stream - the results will almost always be much, much
better then the item by item packing done by ASN.1's encoding rules.  (I
was always amused that using BER, ASN.1 integers were frequently bigger
than simply 32-bit binary, particularly when carrying unsigned numbers,
which are rather common in networking protocols.)

(In addition, with the 60 octet minimum packet size imposed by many data
links, compression of typically small packets - such as those containing
SDP information - often doesn't result in much of a gain anyway.)

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 - I find H.323 to be qualitiatively worse, as measured in units of
elegance, than SIP.  I too am sorry that SIP has gotten more complex as it
has experienced actual implementation pressures.  However, H.323 started
out as a mish mosh - a large dollup of ISDN, a dab of SDP, a chunk of
RTP/RTCP - and it remains a mish mosh.

		--karl--

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 23 Aug 2003 21:31:19 -0700

Hi -

> From: "Karl Auerbach" <[email-masked]>
> To: "IETF" <[email-masked]>
> Sent: Saturday, August 23, 2003 7:03 PM
> Subject: Re: Pretty clear ... SIP
>

> a decades+ old vulnerability for the net.
...

In fairness,
    1) SNMP's (ab)use of ASN.1 pretty much precludes the use of ASN.1 compiler
         technology.  All the implementations I know of used hand-coded encoders and
         decoders.  The vulnerabilities aren't a result of ASN.1, but rather of trusting
         humans to do a compiler's job.
    2) Dean was specifically writing about PER, which can be *much* more compact
        than BER would ever hope to be.  PER can potentially result in a more compact
        encoding than applying compression to a single packet.  Look at the spec to see
        why.

Randy

---

From: Rob Austein <[email-masked]>
Date: Sun, 24 Aug 2003 02:53:24 -0400

>         encoding than applying compression to a single packet.  Look at the spec to see

I've used ASN.1 compiler technology for a project that included an
H.323-related frob, and ended up wishing I hadn't.  Can you say more
than 2MB just for the ASN.1 PER encoder/decoder on a box with an 8MB
flash chip? (For comparision, the embedded Linux kernel on this same
box was quite a bit less than 1MB.)  I knew you could.  No doubt we
could have gotten a smaller implementation if we'd been willing to
throw serious money at it, but H.323 wasn't even the main point of the
box, it was just an extra feature that Marketing hung on the side
because it made a cute demo.  YMMV, but based on that experience I'd
have a hard time believing that ASN.1 PER is worth the trouble.

---

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 24 Aug 2003 15:41:00 -0500

> throw serious money at it, but H.323 wasn't even the main point of the

quick-n-dirty = bloat is a universal. I've seen rfc822 parsers that were
nearly as large for example. As far as that goes, moving bloat around
within a layer doesn't seem to matter much in the end, and ASN.1 parser
bloat is just as bad as XML or 822 or [...] parser bloat.

The question of where compression should occur is a good one. The usual
suspects are the application or the data-link layers, but I'm not sure
there are overwhelmingly compelling arguments for either, or that equally
compelling arguments couldn't be made for transport or network layer
compression for that matter.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Dean Anderson <[email-masked]>
Date: Sun, 24 Aug 2003 17:59:47 -0400 (EDT)

> a decades+ old vulnerability for the net.

This isn't quite fair. Most of these vulnerabilities were hand-encoded, as
are some X.509 (BER) certificate decoders.  Hand-coded ASN.1 suffers from
the same issues as other hand-coded encoders. This is not a flaw in ASN.1.
At least ASN.1 offers a path out.  Ad-hoc text-based protocols won't do
that.

In the few cases where the compilers were are fault, the compilers were
fixed, and applications fixed by relinking.  There are test suites for
compilers that try to crack the generated decoders. This offers a degree
of assurance that can't be found in any ad-hoc protocol.

> encoding data structures into binary for carriage in packets.

XML has its advantages. But mostly, I've found that the biggest advantage
with XML is the ability for hierarchical queries and for hierarchical
storage. Beats the heck out of LDAP.  But this isn't entirely unique to
XML.  LDAP is meant to store a specific type of hierarchical information.
XML is general purpose.  But it is also hugely inefficient.

Another problem with text based protocols, is that when they are
encrypted, they are still ascii.  You know that there is going to be a 0
bit every 8 bits, and you generally know the alignment of the plaintext in
the cryptotext. I note that book that described the DES cracker machine
would brute force every key until it found ascii text.  Unaligned PER
doesn't suffer this problem.  Even if it has large amounts of ascii, there
is no way to determine what the alignment of the plaintext is, without
having the actual decrypted packet. A cracker machine would have a much
more difficult time detecting probable successes.  Further, if you define
the alphabet to be used in the protocol, most regular text is constrained
enough so that it can be sent using 7 bits (and no padding 0's) with
unaligned PER.

> which are rather common in networking protocols.)

When you add in the Tag and length, thats true. But then RADIUS protocol
also uses Tag/Length/Value encoding, although it doesn't call it BER. It
has the same drawback.

And of course, the protocol specifier is free to specify one of 4 variants
of PER. This does not change the semantics of the protocol, and doesn't
affect the specification of the protocol, which can be done roughly
independent of the choice of encoding.  Though, of course, you have to
specify the encoding to be used in a sentence, somewhere in the semantics
of the specification.

> SDP information - often doesn't result in much of a gain anyway.)

Well, there are typically 20 to 40 bytes of header on such links.  On low
bandwidth links, there typically aren't any minimums. And on ATM, a little
compression can make a big difference.

> H.323 -

Few products?  Every Microsoft OS ships with an h323 client called
netmeeting. Now, its h323 compatibility has been criticized (like just
about every other 'standard' feature of Microsoft), but I haven't found
any shortage of H323 products out there.

> I find H.323 to be qualitiatively worse, as measured in units of
> elegance, than SIP.

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.

> I too am sorry that SIP has gotten more complex as
> it has experienced actual implementation pressures.  However, H.323
> started out as a mish mosh - a large dollup of ISDN, a dab of SDP, a
> chunk of RTP/RTCP - and it remains a mish mosh.

Multiple tools make up a toolkit.  H323 uses the right tool for the right
job--something that SIP really missed out on.

		--Dean

---

From: Karl Auerbach <[email-masked]>
Date: Sun, 24 Aug 2003 18:11:30 -0700 (PDT)

> > 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.

> 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.

> 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.

> 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--

---

From: Stephen Kent <[email-masked]>
Date: Mon, 25 Aug 2003 08:33:26 -0400

>a decades+ old vulnerability for the net.

To be fair, the flaws were in an implementation that one person 
developed and many used. The same sort of problem with a 
vulnerability being widespread has occurred in other contexts, w/o 
regard to the encoding scheme. So, this really is a red herring in 
this argument.

>encoding data structures into binary for carriage in packets.

Certainly XML is not going to yield a smaller encoding, so your 
reasons for preferring it have to be based on value judgements in 
other dimensions.

steve

---

From: Dean Anderson <[email-masked]>
Date: Mon, 25 Aug 2003 15:16:17 -0400 (EDT)

> heavy burden of machinery that is present whether it is needed or used or

Karl brings up many good points here.

> quite valid.

> However I would suggest that there is a much greater risk

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.

> embedded devices, we still can't ignore memory and processing

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.

> ability to extend their capabilities in the field.

Agree.

> "complicated" rather than the "intricate" category.

I respond only that things must be made as simple as possible, and no
simpler.

> 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)

> to justify moving away from a relatively solid and fixed-size format to a

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.

> 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.

> 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.

> 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.

> the tap-ability, legal or not, of a VOIP conversation.  What am I not

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 25 Aug 2003 23:49:46 -0700

Aah.... an ASN.1 firefight!
It's been a LONG time since we've had one of those, but they used to be a 
regularly scheduled event on this list.

I used to have opinions on this debate - for a trip down memory lane, check 
out the "canonical X.400 vs SMTP debate" on my website (sorry, typing 
offline at the moment - google will find it).

One note, however:

--On 25. august 2003 15:16 -0400 Dean Anderson <[email-masked]> wrote:

>> 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.
>

One warning to those with long memories and strong opinions:

The way one does extensibility in ASN.1 has changed greatly since the first 
(1984) versions of ASN.1. Lots of the hard opinions people have here are 
based on ASN.1(1984) experience, which was what SNMP originally used.

I have had people tell me that the post-1988 versions of ASN.1 are really 
nice in this department, but haven't used ASN.1 seriously since 
approximately 1992 (when PER was just being stabilized).
So I'm not qualified to say whether they are right or not.

Aside on complexity: The definition of ABNF, the "formal" language used to 
define the SIP syntax, RFC 2234, is 14 pages long, and has been blasted by 
several people as being a too complex tool for proper protocol description.

I haven't checked the pagecount of the ITU recommendations defining ASN.1 
recently, but the last time I had one in hand (X.208/88), I'd estimate it 
as at least 10 times that number of pages.

                      Harald

---

From: Michael Thomas <[email-masked]>
Date: Tue, 26 Aug 2003 09:23:34 -0700 (PDT)

> trustability of such devices.

::snort::