Adding any extra functionality to network applications will always detract somewhat from performance. Security is no exception. For example, the Andrew File System (AFS) implements a great deal of security functionality that imposes a performance cost. Similarly, routers and application-level firewalls impact performance when filtering.
We have highlighted only one example of situations where security measures are added long after initial system design, at whatever layer is convenient or easiest at the time. Other authentication and privacy schemes will have similar problems. There is the danger that users will disregard security because it is not worth the performance degradation. Unfortunately, modifying existing applications and architectures so as to avoid the performance degradation is generally more effort than users are willing to expend. Application designers must be aware of this risk as they design implementations.
In summary, it is no surprise that encryption precludes the ability to perform subsequent compression. It is therefore worth examining its implication for the recent popularity of adding network security mechanisms to extant applications.
Although it is clear that compression should occur before encryption, implementing it properly above the transport layer is harder than kludging it into lower levels, albeit at the expense of performance. We have offered this study to demonstrate that many cases do not require the sacrifice in performance, if only application builders are willing to consider security issues as integral to design rather than an issue to be dealt with later.