The End of the Open Internet?: Network Service and Security in Web 2.0

• Michael Leventhal, Senior Director, Tarari, http://www.tarari.com, Current email : Michael.Leventhal@tarari.comAuthor’s Personal Web Site : http://www.textscience.com

Reflections on XML and Networking

I first heard the question posed over nine years ago at the World Wide Conference #6 in Santa Clara, California. This was at a workshop on the use of XML over the Internet – that was the tentative beginnings of what was to become embraced as the mission of the W3C: to create a new protocol layer on top of Layer 7, creating a standardized sub-strata for applications to use, communicate over, and, effectively, run on the network of networks, the Internet. I think all of us who were advocates in the beginnings of this revolution, perhaps any revolution, are surprised by how far all this has gone. Of course, success is always the least anticipated of outcomes for revolutionaries but even more importantly, individuals become rapidly irrelevant once the technology passes from the cradle to full expansion and one’s individual obsolesce in the face of social phenomenon gives one pause. Pause, precisely, to contemplate that one’s private revolution was ultimately a matter of necessity; if you and your cohorts had not created it others, inevitably, would have done the job. In examining the phenomenon as it comes to exist one must make a conscious effort not see in it the minutiae of its numerous evolutionary strands, both those which were aborted and left it scarred and those were fostered by individuals and competing interests to emerge and survive as dominant characteristics, that which one knows too well to view objectively, but to see the form of the vacuum created by necessity and how a solution grew into that form where other solutions failed to thrive.

I see the question posed nine years ago in the light of these reflections, as a statement turning around the perception of a void that the questioner intuitively sensed; I believe that he only intuitively sensed it because it seemed a spontaneous reaction to being confronted with a new fact and only in the presence of that new fact was he aware that his known universe was circumscribed. The fact was XML and in that very early discussion we were describing the tiniest kernel of what later would blossom into a multitude of things now encompassed by broad category descriptions like Web Services, Web 2.0, and The Semantic Web. The question was “What are the implications of your new messaging and application language, bearing commonly understood semantics in an open format, for the network protocols?”

Somehow we all recognized it at the time as a portentous question but I must admit that I did not, at that time, know enough about network protocols to know even how to begin to think about it. In fact, if I had known more I might have dismissed the question: XML was application data which would be nicely encapsulated in the various layers of network headers and handled like any other application data. But somehow the questioner guessed that XML would not fulfill its grandiose ambitions as just data field bits buried in packets – he became aware of a void that existed between transport and application infrastructure and intuited that XML would fill that void, leading to deeper repercussions on both sides of the protocol stack.

Implied by that question is another, alarming, question. I’ve heard that question posed more recently in another way – again, when I heard the question for the first time I sensed its portentousness without understanding how I was even to begin to think about it. The question was “Is it going to be an overlay?” “It” is the network protocol stack once XML becomes a full-fledged citizen. I now understand the question to be “Are you going to blow the whole damn thing up?” and I also understand why the question was posed with a sly grin and an air of anticipation. For the questioner, a networking industry pundit, blowing things up is cool. Blowing things up creates lots of opportunity – for stimulating debates that fill conferences, for impassioned editorials from techno-journalists, and even for the bean counters, fresh fields of opportunity for busting up a market and creating vast horizons of new opportunity. “Overlay”, I answered, missing, at least that time, my opportunity. “Overlay” means everything will continue working just the way it works now except that will add some cool stuff on top, I thought, and that should be the right answer to this room full of people who have spent there lives building the network infrastructure we have today. So that must be the safe answer. Besides, if I didn’t say “overlay” I will probably be asked what about the network stack is broken and since I wasn’t sure anything is broken I’ll would have ended up looking like a fool in front of all these people. But the moderator looks disappointed so I venture a little something, “Overlay, but we haven’t solved the problem of adapting packet processing to XML, which is fundamentally whole-message oriented.” It’s a risk, I don’t know for sure whether packet processing needs to be adapted to XML or XML to packet processing . I do know from lots of experience with ultra-accelerated XML processing that it is very desirable, but very difficult, to accomplish useful work handling XML in fragments. I know from network design that most of the Internet works as well it does because messages are broken up into packets and routed independent of each other around the network until all packets somehow all show up at their destination where they get reassembled. If XML, as a protocol, contains information that is needed in network intermediaries to get the message to the endpoint how can it possible to packetize it. And how can you not packetize it if XML is an overlay? I don’t have the answer, and I’m not 100% sure it is a good question but I am sure that everyone is at least as confused as I am. My comment, in fact, passes for a profound statement – fortunately your listeners tend to assume that you know what you’re talking about since you are the one that gets to stand at the podium.

I would have liked, however, to have objected to my own statement. To wit, that each layer of the protocol stack follows, with exceptions, its own fragmentation policy, doing what it must do, either because of physics and electronics (e.g., rate at which a frame can be emitted before the preceding frame makes a round trip on the LAN) or cost (e.g., size of buffers per line in a switch) or standards (e.g., number of bits in the header for size of the message). The XML layer could require that the protocol level below assemble the entire message; in any case, it must obey protocol layer abstraction and remain ignorant of the fragmentation strategy executed in the layers below. And this has been done – by no less than a networking authority than Cisco – their first XML networking device handles only complete XML messages.

Counter-argument. The study of networking is a conclusive demonstration of the ascendancy of stepwise-refinement over the technology equivalent of Aphrodite springing full-formed from the brow of Zeus. It seems that every success starts very small and essentially woefully inadequate for the problem that in no time at all it will be called on to solve. Such was ALOHA which become the Ethernet, such was Tim Berners-Lee exercise with a little tag language and a simple get protocol. Such may be unfragmentable XML in devices purported to be network devices.

Transport layers in the current state of the art in networks support fragmentation for reasons that ultimately come down the physics of transmission; there is a significant cost to handling arbitrarily large packets of data and there is today no such thing as a noise-free line. Large packets impact the predictability of network operation, causing congestion and overall degradation of network performance. The probability of transmission errors occurring in large packets, requiring signaling and retransmission of the packet is, naturally, much higher than with a small packet. High-speed queuing and buffering in network devices is subject to physical limitations. A huge amount of tuning of network performance through a number of subnet management protocols would be rendered largely useless if routers and other types of network devices would begin to require the entirety of a Web Services message in order to be able to do their jobs. And large messages constitute a kind of prima facie security threat, as the simple injection of large messages into the network can be a highly effective DoS attack if the network devices must store-and-forward the message in its entirety. So, if XML is to be a member layer on the network stack it must support fragmentation for all the reasons that everything lower in the network protocol stack works that way. Yet, as a protocol header, XML Web Services differs critically from the headers in the lower levels – there is no standard process of fragmentation which produces packets which are sequenced and which repeat header information so that each individual packet can be individually processed.

“Give a good reason for organizing communications protocols into a layered architecture.” Good question, but a follow-up question might be: “Even though organizing communications protocols into a layered architecture is a certified good thing, why is the theory always the one sooner rather than later honored by practitioners in the breech?” Because of the way human beings engineer things – for gods perhaps it is possible to get a headache and produce Aphrodite but human beings get something to work a little bit until they screw up and than they fix it until it screws up again and so on until a pundit gets a gleam in his eye and it is time to blow the whole thing up and start over again. Layered abstraction is, certainly, a wonderful rough approximation, honored in the breach. But you need NAT when you discover that you must hang more than one host off an IP address and need to squeeze in IPSec when you discover that leaving the applications to manage security is about as effective as arming the chickens in the henhouse. The boundaries are no longer clear cut and, in some cases, they are deliberately violated. When we speak of the XML “overlay” we are not comfortable with this overlay sitting over Layer 7. Some say XML is Layer 7 processing but XML Web Services is mostly bound to HTTP and goes over port 80 (or it may be bound equally well to other application protocols and go over their designated port) so maybe it makes sense, as some are saying, to call this “Layer 8” and declare that we have added one more level to the OSI stack. Or not, binding XML Web Services to HTTP was a kludge; Web Services really has nothing to do with a Web Server but as a Web Server evolved into a general program execution engine with the side effect of replying with a browser-displayable page of information it was convenient to hang the Web Services processor off the servlet framework. And HTML is slowly becoming XHTML, an XML browser language, though the masses may chose to ignore the pontiffs of correct form in the W3C for a good long time to come – nonetheless, we can being to think of port 80 as the XML data port instead of the Web Server port.

It was a winning strategy. Don Box’s SOAP 1.0 was, like Tim Berners-Lee HTML, a mere sketch of a solution but you could get it work right away without reconfiguring your firewall, use you servlet engine to create a mini-Web Services server in a few lines of code, and it was cool to play with. Yes, it distorted the true meaning of HTTP (now that HTTP had become venerable) and god knows what kind of stuff – and what kind of security vulnerabilities - had entered on port 80. Those things would be worked out later, if the thing took off.

Well, it has taken off, it has expanded into the void that existing between applications being internet-ified and network becoming application-ified. It remains trivially sitting atop HTTP but stands in somewhat uneasy relation to IP and routing, TCP and connection-oriented reliability, and security/authentication network shims IPSec or SSL. It also magnifies the question of application-level security in the network. It is super-hyped and there may be enough to it that it might turn out to be quite a bit more disruptive than an “overlay”.

Once Web Services entered the world with the experiment of XMLifed remote procedure calls over HTTP its future was laid out in two paths, occasionally appearing to converge – the path of the Committee where standard after increasingly complex standard was developed to offer a full-blown XML-based infrastructure for application networking and the path of the Implementer where the experiments in Web Services and demonstrations of interoperability grew increasingly complex, slowly, but asymptotically approaching the vision of the standards. In speaking of Web Services we must talk about the model(s) (naturally there are multiple and often contradictory models) proposed by the standards and the reality on the ground today. But in this discussion the model(s) taken some preeminence since we are concerned with exploring potentialities that may not supported by the current network infrastructure. It is amusing, now and again, to give the keys to the madhouse to the madmen.

Web Services proposes a one fixed-end connection-oriented process model – in other words, a Web Service request is connection-oriented but the sender does not necessarily know what server will respond to the request. And it gets more complicated – a Web Service response may be composed in multiple hops. The message is passed from one node providing one type of service to another, with each node potentially modifying the data until it reaches the ultimate receiver who consumes the payload and returns a response to the sender.

In Web Services the routing key is not the IP address or identifier of the receiver but the service requested. Web Services envisions a kind of directory, UDDI, which provides a look-up service somewhat like DNS, locating a service provider who can fulfill a particular service request. If the UDDI server works exactly like a DNS in an IP network it will return the IP address of the service provider. The service provider is very likely a proxy; in place or in addition to a firewall there may be one or more Web Services nodes which handle standard parts of Web Services message processing before the message reaches the ultimate receiver. However, there is an important difference between UDDI as a super-DNS and DNS; in DNS there is a one-to-one correspondence between the domain name and the IP address while for a UDDI lookup many servers could potentially fulfill a service request. Selecting the best server to fulfill a request is a routing problem. What Web Services really needs are not IP routers but service routers.

With multi-hop processing we should not have to think of a single endpoint; there is an ultimate receiver responsible for consuming the payload but intermediate nodes, which are hosts are not necessarily acting as its proxy. It may be useful to merge the notion of a router with that of an intermediate processing host. The Web Services message may request authentication, decryption, tracing, acknowledgement or other message operations before reaching the ultimate receiver; the router may compute a path which provides for all requested operations as the message moves toward the ultimate receiver.

In the present day world of Web Services, transaction are generally confined to established end-points and the world is not yet clamoring for service routing. Yet, even simple Web Services are taken on greater and greater overhead associated with routing. The IP address or domain name of the endpoint may be explicitly given in a Web Services request and it may even list desired routing hops. One or more reply to addresses may also be given, with the reply to address potentially based on some condition. Part of the reason for this to achieve protocol layer independence; HTTP is not assumed so the Web Services message requires an independent expression of address information. While this system assumes use of underlying IP routing between Web Services layer routing hops the requirements of Web Services routing are increasingly diverging from the assumptions of IP routing reflected through the transport layer and the conventional (HTTP, SMTP, etc.) application layer.

When thinking of the cost of message manipulation implied by handling routing and other operations one should bear in mind that the XML Web Services message, with its service request and specification of other message operations, is not structured like network protocol headers. There are no fixed length fields in an XML Web Service message and there are typically many optional fields identified by labels; each message can only be interpreted by a special, XML-specific process of scanning and parsing of complex semantics. The separation between header options and payload is difficult to establish. The service requested and other parameters necessary for handling the message in the network can only be determined by a very processing intensive procedure. These processing requirements would seem to render the idea of XML Web Services as a network processing protocol layer highly questionable on the basis of its performance requirements. However, the industry has begun to offer purpose-built ASICs for accelerating XML processing and CPU manufacturers such as Intel have announced plans to augment their current chip sets with XML-specific capabilities. So while XML Web Services message processing may appear complex compared to IP routing, a higher level of hardware capability may solve the performance issue as it once solved it for the IP routing problem.

Service orientation has one other potential implication for routing and switching specific functions related to quality of service and to load balancing. In exposing the service request and other parameters related to the application it is possible for a routing or switching device to make content-specific quality of service and load distribution decisions. In fact, since the payload is nested in the message body and headers it is possible to apply very fine-grained content tests to make handling decisions based on specific knowledge of the application data, a capability which adds an economic incentive toward Web Services to the infrastructure provider in enabling fee-based service differentiation – and also raises concerns about equitable access to the Internet for all categories of users.

As a transactional infrastructure a great deal of work has gone into Web Service security; it is its most complete and robust feature. And it works completely differently from all other security schemes used in the network today. The major difference is that an XML message may be broken up into subparts and any of those subparts can be independently signed and/or encrypted (PKI). The Web Services message contains signatures embedded as well as header information which says what exactly in the document is signed or encrypted and what transformation was used to produce the signatures or encryptions.

Although SSL is currently commonly used for securing Web Services it, and other connection-oriented security like IPSec, are not considered flexible enough for Web Services. Connection-orientation precludes the use of intermediaries able to inspect and act on the Web Services protocol data embedded in the TCP header. And connection-oriented security leaves information insecure at the end of the connection. XML-based security has the interesting property that it makes it possible to protect critical areas of the message but to leave others in cleartext, to sign sensitive data but to allow intermediaries to manipulate headers that is authorized to change. The ability to selectively leave portions of the message in clear text has interesting implications in that it enables service routing, content-based quality of service, and security scanning that makes a qualitative, semantic assessment of message intent.

Web Service also exposes the network to new attacks. One of these is a form of denial-of-service attack based around the fact that handling the XML as a protocol requires XML parsing and the open-endedness of the XML format gives a myriad of ways to obtain resource exhaustion or buffer overflow. The situation is exacerbated by the fact that there are already many simple legacy XML parsers built into thousands of Web Services applications that are very readily broken by such attacks. AJAX applications tend to be constructed in a very ad-hoc way and open the door to many Web Services attacks through the browser. Firewall technology will need to incorporate new technology to cope with these and other types of attacks specific to XML and Web Services.

The amount of complexity in modern computer networks can be eye-opening It can seem foolish to think that Web Services would influence the development of lower levels of the network protocol formats and the extensive management facilities. Everything was designed to work on top of what is already there and, in any case, there is no test bed for anything that might work differently. It seems more probable that the network will have a greater impact on the design of XML and Web Services as a protocol; that which does not work well on top of TCP/IP will die. As with my problem of handling XML fragments, tight integration with TCP/IP and soundness as a Layer 7+ network protocol may force some changes in XML processing concepts. A business case is brewing for application services in the network and application differentiation in quality of service provisioning; it is possible that this will drive the creation of some shims in the network stack to accommodate Web Services methodology. There is Internet 2.0 and those who say Internet 1.0 is broken. XML/Web Services may have something to offer toward fixing the most fundamental problem, security, and have other things to offer to those with the happy luxury of working on a blue-sky design. It would be interesting to see how an application-oriented network would get designed from the ground up.

The Internet is Broken?

There are some people who have been saying for some time that the Internet is broken, really, seriously broken. People who have not been living in caves, who use the Internet every day, and are well aware of all evidence one could point to arguing to the contrary. Some are waiting for the catastrophic event, the Internet’s crash of ’29. But it isn’t necessary to believe in impending catastrophe; if no one believed the Internet was broken it would be broken, but because there are people who believe it is broken, and are working to do something about it, catastrophe will probably be averted as the Internet is continually renewed like a body that in a short time replaces all its cells, effectively becoming a completely new body even though this total transformation is barely perceived.

David D. Clark is one of the oracles of doom. Dr. Clark could be said to be the person who built the Internet in the first place, serving as Chief Protocol Architect fro 1981 to 1989 and chairing the Internet Activities Board.

I agree with Clark, primarily because I make my living from it being broken and I’m making a pretty good living. Among other things, my company sells chips that accelerate inspection of network traffic for malicious content. Already an immensely large segment of the technology market (27.7 Billion $US in 2005!) , Internet security also remains its fastest growing segment (16% per year!). Yet, despite the enterprise's voracious appetite for security equipment and software the network remains insecure and less secure everyday. Wonderful problem for my company; no matter how fast our chips scan traffic the demand remains inexhaustible. Some of the leading computer scientists now say that no amount of conventional network security equipment - whether SSL, VPNs, IPS, UTMs, and Firewalls - will ever "solve" the security problem. "The internet is broken", David Clark says, and its fatal flaw is its lack of built-in security. "We are at an inflection point ... where the utility of the Internet stalls - and perhaps turns downward," sprak the doom-sayer. [See http://www.technologyreview.com/InfoTech-Networks/wtr_16051,258,p1.html, The Internet is Broken, by David Talbot, Technology Review.

The essential point is that even without an impending inflection point, with $27.7 billion in spending in 2005, rising at 16% a year to $58 billion in 2010 and all that money merely keeps the problem at bay, how can anyone say the Internet is not broken, seriously broken? And will we see the inflection point? Well, consider that the Internet has, up until this point, had limited use – email, Web pages, file transfer, limited b2c. Web 2.0 and Web Services enable wide, transactionally-heavy and business-critical b2c and b2b and even a generalization of business operation to through the Internet. On the same infrastructure that we agreed a moment ago is seriously broken.

Growth of the Market for Internet Security, Source: BCC Research

More Security or More Secure Content?

We arrive now to our core propositions: the use of XML both as a protocol and a payload for Web Services and Web 2.0 applications has the potential to alter the fundamentals of network operation and, by consequence, the problem of network security. The reason for this is information topography.

Traffic in the network today has little topography. It is a basic principle of packet-based switching; the network infrastructure should know as little as possible about the content of the packet. All packets are equal. Knowledge equals brittleness and huge overhead. "...the more you ask the network to examine data ... the less efficiently it will move the data around,” according to Vincent Cerf. The exception proves the rule, always; protocol headers always have special little fields that were intended to give some topography to data, to make one packet look different than another so it be handled differently. Sometimes these fields are used, sometimes not. But this fundamental principle is changing under the force of irresistible pressures – technological and, ultimately, economic. More and more topology is being added to data unit to differentiate one packet from another. A new-old idea, QoS, providing guaranteed service levels and reliability like the phone system, is driving a lot of this, especially as demand for the triple-play (voice, data, video) necessitates variegated delivery requirements. In the same way that many of the fundamental principles of efficient program design became superseded by the principles of efficient lifecycle management of computer programs because it was found that the greater cost lay in building systems and maintaining them than in making efficient use of the underlying hardware, the networking world is finding that getting packets from A to B as efficiently as possible is superseded by the economic imperative of being able to offer value-bearing and differentiated services and service levels in carrying connecting customers paying to exchange data.

We are able to discuss the ability of XML to bring topology to information only because the discussion of information topology in the network has already been long underway, making minds receptive to the possibilities.

Before I go into the potentialities of XML and its information topology in the network let me acknowledge that it begins with the irony that it introduces new vectors for threats into the network, and that entirely due to all the qualities that enable the potentialities. One class of threats are due to numerous vulnerabilities in XML infrastructure components; little or none which was designed to be robust from the point of view of network security. Parsers, for example, can easily be brought down through an almost infinite number of tricks in message composition. Which might not be a very big deal if you are running an XSLT conversion at your desktop but could shut down the eastern seaboard in a sophisticated distributed denial-of-service of attack. Web Services infrastructure (WSDL, UDDI, and so on) and, generally expose information about business processes, opening enterprises up to hackers who use public knowledge to deduce critical information and mount an insider attack. The transparency and accessibility of XML make such attacks, often attacks that use XML injection, a fundamental concern to network security. Securing the channel, through SSL for example, is problematic for loosely-coupled web services but even more importantly, doesn’t protect the end-points or information flow within the enterprise. And securing the channel doesn’t protect the network in general since not all exchanges are or can be secured and attacks mounted through insecure channels can impact the performance on all channels. To finish with this grim picture, interactive and semi-autonomous technologies like AJAX can easily turn any browser into a zombie for mounting distributed DoS attacks.

XML Threats

And let us also say that all that a new possibility is not necessarily something that you would think good About that, more later.

A Study in XML Information Topology: XML Steganography

I would like to begin to explore the information topology of XML with something peculiar, the result of an artifact of XML construction owing mainly to what may be its bad design, certainly from a networking perspective where nearly satanic practices such as Canonicalization are a direct consequence. And although this artifact could certainly have the practical application described here it has never been so used – to my knowledge. Yet the topic is fun to think about and the lesson learned when one understands the principles applied is deep, perhaps even of the most fundamental importance.

This peculiar diversion is XML Steganography. Steganography, from the Greek words for “covered writing”, is the practice of hiding messages such that it is not apparent that the hidden communication is taking place at all. Cryptography, by contrast, allows secret messages to be sent, but the actual fact that a secret message is being sent is apparent to anyone in possession of the message.

Steganography has received a great deal of attention in recent years due to the suggestion that terrorists might be using this technique to communicate. As all likely channels of communication used by terrorists are closely monitored, the simple fact that a communication between two suspect parties has taken place is useful intelligence and increases in the volume of communication over monitored channels is also of value in counter-intelligence. Steganography, on the other hand, would allow the terrorist to use public broadcast communication such as Web pages to send hidden messages which can be seen by anyone but only understood by those who know where to look and possess the steganographic key for decrypting the message.

One well-known steganographic technique is pack the hidden message into insignificant bits in image data. For example, in the image (Saint Olga planting Christianity in Russia, symbolized as a tree) on the left below each pixel is encoded in 24 bits, 8 each for the red, green, and blue intensity of that pixel. In the image on the right the least significant bit for each color of some number of pixels was used to encode a hidden message – The Gospel of Judas in its English translation by Kasser, Meyer, and Wurst.. The original image size was 500x320pixels, giving 961,000 bits or about 120,000 bytes for a hidden message and quite more than enough for the short text of 17,845 bytes. The human eye cannot detect any difference between the full 24-bit color of the image on the left from the slightly modified image on the right.

A message is embedded in the right image using steganography

XML is a document format that is particularly rich in yielding possibilities for steganography: the difference between serialized XML and the infoset is the main feature of the format which allows many options for hiding information in an XML document. The basic steganographic technique for XML is to use insignificant bits (bits which do not alter the infoset) to encode information within the carrying XML document. While typical steganographic techniques in images actually do change the carrying document, albeit in ways that do not impair its information value (e.g., because the human eye cannot perceive the alternation) XML steganography does not alter the carrying document which is defined to be its infoset and not its serialization.

Here are a number of ways to insert hidden message bits that could be used in an XML document:

1. Use of different types of insignificant white space

2. Use of white space in tags

3. Use of either one-tag or two-tag empty elements

4. Use of legal but ignored markup like comments, internal subset, empty CDATA section

5. Use of character entities

There is information which can be embedded when a schema or DTD is used to produce the infoset:

1. Use or omission of default attributes

2. Changing order of a model group of unordered elements

Information can be embedded if you have rules about the processing style:

1. Elements with PCDATA content models without data are steganographic symbols.

2. Synonymous elements are used.

3. Use of useless but legal elements.

Here is an very simple example of an algorithm for embedding a steganographic message in an XML document. Every consecutive 5 tags in a document carries the bit encoding of a letter, punctuation or a signal such as the start of a number or end message. If the bit is ‘1’ the element must contain white space in the tag just before the end-tag symbol and if it is ‘0’ it must not contain white space between the last markup in the tag and the end-tag symbol. Here is the encoding key:

Example Stego Bit Code

And now here is a document with a steganography message:

A Steganographic XML Document

In the very simple example above, the amount of information encoded relative to size of the carrier message is small – a total message size of 25528 bits to carry 90 bits of hidden text, comparing unfavorably to the capacity of a graphic steganography where in a JPEG 3 bits per 24 bits may be used for hidden text, albeit with information loss and excluding consideration of the considerable amount of non-pixel data in the format. However, the number of ways to encode information steganographically in an XML document is large and with so many axes of insertion (and their cross-combinations) the relative density of hidden text could be extremely high. XML also allows the insertion of hidden text of any length, as there is no intrinsic limit of not-significant bits that can added to the document without altering its infoset.

How much information can be hidden in an XML document? In fact, there is no limit given that an infinite information may embedded without altering the infoset of the document. Not a huge amount as a large JPEG might give, but quite enough for a rough test of authenticity. After all, a single bit in a varying steganographic signature could be enough to give a weak verification of authenticity and make a deep improvement in the overall level of trustworthiness of XML traffic.

XML Meets the Network: Application-Aware Networking

Application-aware networking is one of many terms industry is using now to describe the concepts and products that has resulted from the intersection of XML and the network. Another new-old idea, application-aware networking relates to telecommunication industry’s concept of the intelligent network, proposed over 20 years ago, and to debates going back to the dawn of networking on service provisioning and how best to provide guaranteed service and reliability. XML, however, introduces a radical new twist on the discussion, as indicated already in our examination of XML as a Layer 8 protocol. XML networking is also converging with the rapid evolution of voice and video over IP; application data, as the third leg of the triple-play, shares some basic operational network concerns with the other two and, besides, the whole world is due for a shakeup.

Defining application-aware networking is a little like that joke where a man asks three people what 2 plus 2 is, a psychotherapist who tells him with a year of therapy he will understand why he is asking this question, an engineer runs off and designs a neural network computer to answer the question, returning after six months (5 months past schedule) with the reply that there is a 87% probability that the answer is between 2.9 and 4.4, and a lawyer who asks the man how much he is willing to spend to get the answer and well-satisfied with the magnitude of the sum given in the response puts his arm around him as whispers confidentially, “How much do you want it to be?” Application-aware networking is an existential question, a science project, and, for the vendors, whatever the customer wants it to be. None of which is meant to say that the possible benefits and problems solved aren’t real, just that the technology is in that fluid phase where you are sure that something significant is happening but no one is able to say how all the pieces will fit together once they thing becomes really big.

The main application-aware networking services that are talked about today are routing, security, and application-to-application connectivity. We’ve discussed routing and service architectures already in our discussion of XML as a protocol. We’ve discussed the problem of network security and how XML structural topography can be used to render the network a little more wholesome; of course, application-aware networking devices do more conventional operations such as WS-Security and can apply XML Schema Validation and XML content rules (e.g., XPaths) to tightly secure known application-specific XML data streams. Application-to-application connectivity is still waiting, to some extent, for the enterprise software world to decide if and how it is going to use an intelligent networking infrastructure to enable better inter-application operation over the Internet. Right now, it mainly means the ability to do data transformations using XSLT, a bit like the hub concept from b2b, another ancestor of application-aware networking. Another possibility is providing binary XML gateway services, potentially offering improved network performance through compression and improved application performance through services such as XML index generation. The application-aware networking device at the perimeter appears to also be a good place for the capture of business intelligence and also for checking regulatory and corporate policy compliance on both inbound and outbound traffic.

Final Thoughts

While no one is saying that the open data formats and extensive use of XML in Web 2.0 is a bad thing, there is a tad of irony in fact that open data facilitates application service-level discrimination that many fear as the end of the open Internet. While it possible that legislation will forestall the carrier’s profit motive from becoming the organizational principle of the Internet it seems to me that there is an irresistible momentum toward a new order as other forces such as the persistent security threat and the introduction of many real-time IP services converge with the ramp up to network application-awareness. The TCP/IP network stack is obsolete in fundamental respects, although patches like MPLS have been successful in extending its life. It seems that QoS is a real requirement resulting not only from volume but also the qualitative aspects of network traffic. It seems that a more secure foundation, more naturally attack-resistant is necessary. Structural and semantic information topography is like a more solid and stable frame on which to construct a robust networking body. I think of the relation of networking to XML today like Bosak was thinking of relation of Java to XML 10 years ago; it gave Java something to do. Now it is time for XML to give the network something to do. It is reverse-entropy; the universe is becoming more ordered. XML is a pure mental exercise and as such can defy the laws of physics.