Payload Protection

What information does the service provider need in order to deliver the required service? Is the service provider permitted to use or retain this information for any other purpose?

Martin Geddes asks whether a telecoms carrier is entitled to analyse the content of your communications, or does this count as wiretapping/wiretrapping (Telepocalypse, Feb 8th, 2005). For example, it seems that deep packet inspection tools are available to ISPs, which enable an ISP to charge more for certain types of usage (differentiated service).

Obviously it is always possible to design more security into these service relationships. You can encrypt all your communications, and then expose just-enough information to your service provider, on a need-to-know basis. Or you can create microservices to encapsulate identity and context, which your service provider invokes as needed. But this added security may have a bad effect on performance or flexibility. And a service provider may simply respond to your evident lack of trust by putting you onto the maximum tariff anyway - using the performance overhead as a convenient excuse.

Paradoxically, deep content inspection is also practised for security purposes. For example, here is a glowing and uncritical product description of the Teros Web Services Security Gateway, written for Teros by industry analysts Zapthink (pdf). Of course, security has always provided the most common justification/pretext for intercepting and eavesdropping communications. But such mechanisms require proper governance and oversight, to make sure they are appropriately used and do not themselves introduce vulnerability, information leakage, or excessive overhead. Zapthink should read The Perils of Deep Packet Inspection by Thomas Porter of Avaya (Security Focus, Jan 2005), which identifies a number of recent vulnerabilities introduced though deep inspection.

In a service oriented architecture, we talk about the payload (business message payload, service payload) that is passed between the service provider and the service consumer. RosettaNet (RNIF Version 2.0 onwards) allows for encryption of the payload (or payload container). Encryption is supported by some of the web integration platforms. (See for example, BEA WebLogic Integration.)

So when should we permit deep inspection, and when should we use encryption to prevent deep inspection? This is essentially an architectural question, and requires us to think topologically about information sharing and information leakage. One of the architectural advantages of encryption is that it helps to enforce a given stratification, and provides some assurance of separation between the different layers. While deep inspection may be appropriate in some situations, it complicates the topology; don't permit it unless you understand the implications.