next up previous contents
Next: WAP - A Basic Up: The WAP Trap An Previous: WAP - A Procedural   Contents

Subsections

WAP - A Technical Failure

In addition to its procedural flaws, the WAP specification also includes serious technical deficiencies.

A detailed technical criticism of the WAP specification is beyond the scope of this document, and in this section we will do no more than provide a brief summary of the major issues. For a detailed analysis of WAP, the reader is referred to the article W* Effect Considered Harmful [13], in which author Rohit Khare argues the shortcomings and ultimate non-viability of the WAP specification.

The deficiencies in the WAP specification are glaring, obvious, and readily apparent to any competent data communications professional. A recent (January 2000) e-mail discussion thread on the IETF mailing list [7] makes this point quite plainly - this thread demonstrates clear consensus among professionals that the WAP specifications are not a technically sound engineering solution.

Many of the technical problems stem from a strategic design decision, made early in the design process. As noted in the Introduction, a new set of protocols are clearly needed to address the efficiency needs of mobile wireless devices. One approach to this would be to treat these devices as just another kind of Internet host. Under this approach, the existing Internet protocol architecture would remain in place, and to this would be added a small number of supplementary Internet protocols, designed to provide the power and bandwidth efficiency required by wireless devices and networks.

The other approach is to treat these mobile devices as a unique special case, requiring their own, entirely new set of protocols. Under this approach, the existing Internet protocol stack is discarded, and a completely new protocol stack is re-designed from scratch.

The WAP Forum made the early strategic design decision to take the latter approach. They have developed an entire stack of network protocols analogous to, but largely incompatible with, the existing Internet architecture. Not only has this approach required an enormous engineering effort on the part of the protocol designers and implementers, it has also given rise to a number of fundamental design errors.


User Interface Assumptions

A basic principle of data communications protocol design is that communications considerations must be de-coupled from user interface considerations. In other words, user interface issues must not be part of the protocol.

The WAP specification, however, violates this principle completely. It is tailored primarily to the physical characteristics of the hand-held mobile telephone, with its unique user interface characteristics. Accommodation is made to these characteristics throughout the specification, with the result that user interface issues are repeatedly combined and confused with communications issues. To put this in the language of data communications professionals: WAP presumes presentation.

The WAP designers justify this on the grounds that the combined technologies of wireless communications, and the mobile telephone, create a unique special case which warrants this departure from standard design principles. In fact, this is a strategic design error.

Extreme Accommodation to Existing Networks

Because WAP is essentially a marketing construct, one of its goals has been to create mindshare within every segment of the wireless industry. In order to accomplish this goal, WAP has made extreme accommodation to existing wireless networks. The WAP specification claims to accommodate almost all existing networks, including several which are already obsolete in their usage and general design. This has significantly and unnecessarily increased the complexity of the specification.

The WAP specification claims to support all the following wireless networks: CDPD, CDMA, GSM, PDC, PHS, TDMA, FLEX, ReFLEX, iDEN, TETRA, DECT, DataTAC, Mobitex, SMS, USSD, CSD, IS-136.

Some of these networks, such as FLEX and ReFLEX, are not general-purpose wireless networks, and were neither intended nor designed to run Internet-centric application protocols of any kind. WAP's decision to accommodate such networks makes little sense in engineering terms. This decision can only have been based on marketing considerations - each additional network supported provides WAP with one more promotional bullet point. Engineering concessions to marketing are a fact of life in the world of consumer products, but they have no place in an industry-standard protocol.

Wireless networks are rapidly standardizing on IP, the Internet Protocol. Most modern wireless networks (e.g. CDPD, Packet CDMA) already support native IP, and we can expect that others will do so in the very near future. The convergence of wireless networks on IP at Layer 3 (the Network Layer) is already a technological reality, and it is inevitable that it will eventually become standard on all networks.

Therefore the correct approach to wireless application standardization is to accept IP as the standard service at Network Layer, and implement high-efficiency protocols above Layer 3.

Furthermore, the result of accommodating all these networks is that the specification is no longer Internet-centric. WAP insists that the specification is Internet-centric, but this claim is without substance. If one tries to accommodate all existing technologies one cannot claim that the result is Internet-centric - one simply cannot have it both ways.

WAP claims to achieve accommodation of this very wide range of networks by means of two lower layer protocols: Wireless Control Message Protocol (WCMP), and Wireless Data Protocol (WDP).

WCMP is an out-of-place imitation of ICMP. Since there are no multiprotocol wireless operators, use of WCMP is always addressed as a service provider specific mechanism. In other words, WCMP is largely irrelevant.

WDP is roughly equivalent to UDP. The only rationale for its reinvention is to accommodate airlink addresses and airlink restrictions on packet size. The equivalent of WDP could have been accomplished on a per-network basis outside the scope of wireless applications. In fact, the existence of WDP may become a hindrance towards evolution of existing wireless networks towards IP.

In general, backward compatibility is a worthy design goal. But in this particular case it is a wasted effort. The convergence of wireless networks towards IP is already a technological reality. The strength and benefits of ``IP On Everything'' by far outweigh the efforts in accommodation and backward compatibility.

WAP's choice has been to accommodate all existing old wireless networks - a fact which betrays its underlying market motivation.

Excessive Re-Invention in the Name of Wireless

Existing Internet protocols do not adequately meet the requirements of wireless data communications - on this point we are in complete agreement with the WAP Forum. However, we believe that the correct way to design the required protocols is to do so within the framework of the existing Internet protocol architecture - the new protocols should be compatible with and re-use existing protocols as much as possible.

The WAP designers, however, have taken precisely the opposite view. Instead of re-using existing protocols, they have created an entirely new set of protocols from scratch.

The main key piece of new technology in WAP is the Wireless Transaction Protocol (WTP). In many ways, WTP is the heart of WAP. WTP is responsible for delivering efficient reliability to applications. Even in that area, WAP could have re-used existing technology. Specifically, T/TCP [2] and ESRO [14], which had already been published as Internet RFCs, could have been used. While there may be some reasonable objections to the use of T/TCP due to its ``heaviness'' because of bundling with TCP, there is no reason why ESRO could not have been used instead of WTP. In fact, WTP is a poor attempt at accomplishing the services of ESRO.

Aside from WTP, in most cases WAP's new protocols are essentially the same as the previously existing protocols, but with minor modifications that render them incompatible with the original standard. The WAP specification discards and then re-designs almost every existing Web standard - for example, WAP replaces UDP with WDP, TLS with WTLS, HTTP with WTP, HTML with WML, and ECMAScript with WMLScript.

This large amount of re-invention is entirely unnecessary. There are many places throughout the design of the WAP protocols where the existing protocol structure could have been left untouched, but complemented by the addition of a limited number of new protocols, designed for optimal efficiency.

The scope of the WAP specification has also been expanded beyond what is needed or reasonable (e.g. WCMP, WDP). Again, the WAP designers justify all this re-invention and expansion of scope on the grounds that wireless mobile devices present a unique special case, requiring a completely new set of protocols. In fact there is nothing specific to wireless applications which justifies this exhaustive degree of re-invention.

Vulnerable Wireless Transport Layer Security (WTLS)

In his paper Attacks against the WAP WTLS Protocol [9], author Saarinen describes in detail a number of security problems with WTLS. Here we provide a brief summary of the problems and their cause.

Although the WTLS protocol is closely modeled on the well-studied TLS protocol, a number of security problems have been identified with WTLS. These problems include: vulnerability to datagram truncation attack, message forgery attack, and a key-search shortcut for some exportable keys.

Most of the text in the WTLS specification has been adopted, word for word, from the TLS specification. However, many of the changes that were made by WAP Forum have led to security problems.

This is another case of the WAP Forum's deliberate deviation from the mainstream of the Internet causing difficulties.

Bungled Protocol Number Assignment

As Khare discusses in greater detail [13], WAP's port numbering strategy is another example of botched reference-by-copy. Instead of obtaining legitimate WAP ports in the IANA-registered space, WAP uses the temporary private port space in the range of 49152 to 49159. In addition to the port numbers, TLS ciphersuite codes and HTTP methods were also not registered with IANA. Instead, the WAP Forum has created its own parallel IANA equivalent called WINA.

This is another case of WAP Forum's deliberate deviation from the mainstream of the Internet in the name of wireless, and for the purpose of maintaining control.


next up previous contents
Next: WAP - A Basic Up: The WAP Trap An Previous: WAP - A Procedural   Contents