| Project LongJump — an Architecture for Low Cost, Secure Internet and Wireless Services | ||
|---|---|---|
| <<< Previous | The LongJump Architecture | Next >>> |
The network protocol between the client and server has a broad impact on the operation of an Internet-based application. While it is possible to work around a poor protocol, it does take a great deal of effort. Wrong decisions in the area of protocol design make it much more difficult to build a secure system with acceptable performance. Additional hardware and bandwidth costs imposed by an inadequate protocol can also be very high. Often, an error made at the protocol level is not easily changed, due to the need to upgrade multiple clients.
A good protocol design has the following characteristics.
Low bandwidth usage.
Low processing overhead.
Simplicity (this makes security much easier to achieve and helps greatly in debugging).
Extensibility.
The above features remain relevant even when the service being built is web-based. For example, generating simple HTML documents and minimizing the use of images will result in a relatively efficient, easy-to-process "protocol". One major advantage of web-based solutions is that many changes to the HTML output carry a relatively small penalty. At worst, the look of the site is altered, but the users may simply continue accessing the service with their browsers.
When a custom protocol must be developed, a plaintext design (e.g a command name followed by arguments, or name-value pairs) is the best general approach for most Internet applications. Such designs are quite easy on network resources. They also simplify system troubleshooting, because no specialized tool is required to look at the messages. For wireless services, low bandwidth usage is particularly important, because current wireless networks may be slow and unreliable.
The current popularity of XML cannot be overstated. When used correctly, this technology can be helpful. Unfortunately, an unsophisticated XML deployment will do a lot more harm than good. One very troubling example of this trend are XML-based network protocols, which specify the transmission of raw XML documents between the communicating systems.
Unfortunately, a protocol that relies on transmitting XML documents almost always uses many times more bandwidth than even the most naive non-XML design. XML transmissions are also very hard to read (thus complicating debugging) and impose a significant processing penalty for parsing messages.
An adverse impact on security is perhaps the most significant fault with "over-the-wire" XML. XML messages require the use of a very complex parser — just the sort of system that attackers like, simply because complex things can be broken in so many more ways than simple ones. If an application is built with a perimeter filter to protect the parser, however, it runs again into the very same problem. The perimeter filter itself would have to be a mini XML parser — making that filter much more complex than would otherwise be necessary.
An effective way to use XML is as a specification language, not for the actual implementation. This is similar to the relationship between the source code and the compiled program. The programmer writes source code, which the compiler then processes to obtain the final result. A concrete example in the XML world is the DocBook format [Wal99] for technical documentation. DocBook files are converted by a suitable processor into a form suitable for printing or online viewing.
The following steps show how to create a network protocol using XML, without incurring the disadvantages of sending raw XML documents over the wire.
Specify the logical structure of the protocol (e.g. via an XML DTD or schema).
Define an interface for the transport layer for your protocol.
Specify the transport layer using XML.
Develop a conversion tool that takes the documents from steps 1 and 3 as inputs, and generates a set of templates (e.g. printf-style format strings) for the complete protocol.
Using a separate transport specification makes it easier to adapt the overall protocol (e.g. transitioning from TCP virtual circuits to UDP datagrams can be done without rewriting the logical structure specification). Another advantage is that the conversion tool is an external, offline program. It can be written in any language, using any available XML parser. Neither the programming language of the application itself nor its runtime requirements have any effect on this tool. In particular, the heavy security and performance demands that must necessarily be imposed on any online XML processing system are not applicable to the conversion program.
The final result is an XML specification, which is processed into a simple runtime format. Thus, the full benefits of using XML are retained, while the harmful qualities of an overly literal XML deployment are avoided.
| <<< Previous | Home | Next >>> |
| System State Consistency and Security | Up | The Custom Client |