On Sat, 23 Aug 2003, Karl Auerbach wrote:
> 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. 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. > 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. 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. > 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.) 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. > (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.) 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. > 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. 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