Traffic masking in IPsec: architecture and ...

Traffic masking in IPsec: architecture and implementation Csaba Kiraly, Giuseppe Bianchi, Fabrizio Formisano, Simone Teofili, Renato Lo Cigno

Abstract – Protection from statistical traffic analysis attacks calls for effective design of Traffic Flow Confidentiality (TFC) mechanisms. These are devised to alter the traffic pattern in order to hide information about contents transmitted, which, despite encryption, can be revealed by malicious users through statistical analysis. Widespread diffusion of these mechanisms requires embedding them in widely deployed protocols. This paper proposes an IPsec based framework aimed at enforcing TFC. This is characterized by two key components: i) a module designed to enforce packet padding, fragmentation, dummy packet generation, and artificial alteration of the packet forwarding delay, and ii) a TFC header devised to carry information across the IPsec tunnel to allow packet handling at the receiver side. The proposed approach has been implemented in a Linux 2.6 Kernel, and preliminary experimental results are reported to show its operation. Index Terms—privacy, security, IPsec, Traffic Flow Confidentiality, experimental assessment

I. INTRODUCTION Although encryption is sometimes considered as an effective means to guarantee the confidentiality of the communication, a closer look at recent literature shows that it is not sufficient to fully protect the privacy of communications. Indeed, the pattern of the traffic generated in a communication carries a lot of information. From the analysis of the traffic patterns, a third party may disclose information such as the application layer protocols and services employed [1, 2], and/or the nature of the specific contents downloaded [3, 4]. Moreover, traffic analysis can be used to deploy passive or active timing attacks in order to break security protocols such as SSH and TLS [5, 6, 7], or to obtain a remote physical device fingerprint [8]. Encryption is not designed to mask the statistical characteristics of the generated traffic (packet sizes, inter-packet times, etc), so it does not help. To protect against such attacks, further mechanisms are needed in addition to encryption. These are frequently referred to as "Traffic Flow Confidentiality" (TFC) mechanisms. TFC mechanisms are designed to prevent an eavesdropper from recovering information about the user’s activities exploiting the statistical characteristics of a data flow. TFC artificially alters the characteristics of each traffic pattern modifying the number, the size and the inter-arrival times of the packets exchanged. We point out how important TFC becomes in wireless environments, where eavesdropping is extremely easy, and it is also easy to associate traffic to people identity with simple This work was supported by the IST project DISCREET, contract number 27679. C. Kiraly and R. Lo Cigno are with CNIT / University of Trento; email: {kiraly,locigno}@dit.unitn.it; G. Bianchi, F. Formisano and S. Teofili are with CNIT / University of Roma Tor Vergata; email: {giuseppe.bianchi, simone.teofili, fabrizio.formisano}@uniroma2.it.

techniques of signal processing. Once this association is done, information privacy is jeopardized. Although several TFC approaches were described in the literature, typically they are either devised as extensions of specific applications [9, 10, 11, 12], or developed in the frame of Mix-like anonymization protocols [13, 14, 15, 16]. As such they have no clear decoupling of the TFC functionalities from the anonymous routing features, thus limiting their widespread adoption. TFC extensions have been recently considered also in the IPsec Encapsulated Security Payload (ESP) version 3 [17], but the level of specification is, to say the least, minimal, as discussed in Section II. To face these issues, one of the challenges of the ISTDISCREET project is the design and implementation of the TFC approach described in this paper. The TFC design requirements are the following: i) develop TFC as a separate protocol, for modularity reasons; ii) clearly decouple TFC from anonymous routing protocols, that can possibly run on top of it; iii) enable its natural and backward-compatible integration within IPsec as a super-layer of ESP. The specific choice of IPsec as base platform for TFC was motivated by a number of reasons. First, IPsec provides a framework for security services at the network layer; for this reason it is amenable to support a multiplicity of services. Second, IPsec is witnessing a significant deployment in the frame of wireless networks. The availability of bump-in-thewire or system-on-chip implementations allow its integration even in hand-held devices, and the IPsec key exchange mechanism has been recently extended to fit mobility [18]. The remainder of this paper is organized as follows: in Section II we introduce our TFC design, its components, and we show how it integrates into the IPsec framework and into the protocol stack. Section III is dedicated to the discussion of the implementation details as a Linux kernel module. In Section IV, we evaluate our design and implementation by running several applications with TFC protection. Conclusions and current research issues are provided in Section V. II. IPSEC TFC DESIGN To the best of our knowledge, the first attempt to provide standard elementary TFC mechanisms is represented by the last IPsec specification. This represents, to date, the only example of a widely deployed security protocol which has included specific TFC mechanisms, specifically as part of the new ESP (version 3) protocol [17, 19] (unlike, for instance, the latest version of TLS [20], which doesn’t even mention the problem of TFC). IPsec may play a significant role in fostering the widespread dissemination of TFC as a basic security service to be considered in addition to

authentication and encryption. In spite of this, IPsec TFC support is limited (it is not a case that the IPsec specification [19] refers to "limited Traffic Flow Confidentiality"). The IPsec (more specifically ESP version 3) specification, in fact, provides only a subset of the possible TFC mechanisms: − a mechanism to discard dummy packets (identified by the value 59 in the next header field); − a variable size field to realize an arbitrary padding of the packet (besides the short padding allowed for encryption algorithm or alignment reasons). It should also be noted that even this latter is applicable only in specific cases. For backward compatibility reason no management of TFC padding is provided (indeed, there is not an explicit TFC pad length field as part of the ESP header), and thus such padding can be added only if the next layer protocol contains a length field1. Another aspect that has to be underlined is the lack, in the ESP specification, for a mechanism to artificially alter the packet forwarding time. While dummy packets intertwined with the real ones may in principle cover such information, nevertheless traffic shaping techniques may reach the same protection goal with no extra burden on the network load. Furthermore, the IPsec specification does not provide local management controls to enable the use of TFC padding and dummy packet generation. The interface that allows the user to specify a TFC mechanism and its parameters is not specified. To the best of our knowledge, there is no public domain IPsec implementation which provides a way to control these capabilities. A. TFC basic mechanisms Instead of the limited set of tools provided by the current specification, we propose to separate TFC functionality into a specific sub-layer, and thus present a solution that provides a complete set of tools to masquerade the original traffic pattern. These basic TFC mechanisms can be categorized as follows: − Packet forming (padding, fragmentation, etc.); − Packet timing (queuing and de-queuing); − Dummy packet management (generation and discarding). To overcome the limitation of current IPsec padding support and to introduce other types of packet forming such as fragmentation, an explicit TFC header is necessary. Figure 1 provides the structure of the TFC header and its placement in the stack. TFC wrapping IP HEADER

ESP HEADER

NEXT HEADER

TFC HEADER

PAYLOAD SIZE

PAYLOAD

FRAG & FLAGS

TFC PADDING

ESP TRAIL ER

ESP AUT H

TOCT

Figure 1: The TFC header format and its place in the protocol stack.

1

This is always true in tunnel mode, where the payload data is the tunnelled IP packet. It is also true in some transport mode cases, e.g. when UDP or ICMP packets are encapsulated, but we point out that a notable exception is indeed TCP which does not provide an explicit segment size field and thus cannot be padded beyond the 255 bytes short padding limit.

It contains explicit information about the payload size, the IANA allocated number of the next header and flags to control QoS support and other TFC functionalities. Due to space limitations, further details of the role of flags are not discussed here. Dummy packets are identified by the value 59 (designated by IANA as “no next header”) written in the next header field, and as such the packet should be discarded as soon as the processing of packet headers arrives to the field containing this identifier. Setting 59 as the next header of ESP or of TFC results in the same behaviour of the packet being dropped; however, it is conceptually cleaner to group TFC functionalities in one layer and thus provide the information identifying packets as dummies in TFC’s next header field. Finally, packet timing (i.e., delay in forwarding) does not need any explicit support in the header. B. TFC Control Logic The basic TFC mechanisms introduced above are the building blocks for the TFC functionality. The glue putting them together is the TFC control logic, which decides about the application of these building blocks on a per-packet basis, and combines them into an effective protection against traffic analysis. The control logic is responsible for the implementation of the traffic flow confidentiality security service by modifying the traffic pattern of a given Security Association (SA) in a way that masquerades the real traffic flowing inside the SA. This can be achieved according to a large variety of TFC control algorithms, differing in their complexity, in the level of protection achieved and in the overhead introduced. C. TFC Control Algorithms The design of effective control algorithms is the cornerstone of the TFC security service. Our implementation does not impose the usage of specific algorithms, but provides a general framework to develop, experiment and assess different algorithms2. Clearly, the simplest and most straightforward algorithm consists in embedding the SA’s traffic in a CBR traffic pattern (with packets of constant size and a constant packet inter-arrival time). Such algorithm is ideal in the level of protection, it has a low complexity, but it also introduces serious performance drawbacks both in limiting the throughput and in filling the network with padding and dummy packets. It is worth noting here that besides CBR, any traffic pattern that is independent of the original traffic flowing in the SA has the same properties. Algorithms can also generate traffic independent patterns using stochastic processes (modifying packet size, timing, or both). Other control algorithms are the adaptive ones, where the output pattern depends on properties of the original flow. Some examples are random size padding, random introduced delay, or a rate adaptive CBR. 2

We remark that the goal of the present paper is to present a TFC architectural framework which allows an easy implementation of traffic masking approaches. The goal of proposing and assessing the protection/overhead trade-offs for specific and possibly novel traffic masking algorithms is left to further research.

TCP/UDP

IP (tunneled)

Onion Routing

ESP/TFC SA level interfaces

Flow filters and priorities

Type of TFC treatment

Control Logic

TFC SA Manager

Dummy parameters

Queuing policy

−

Algorithm parameters

Basic Functions

Dummy Packets

− Packet queuing

Dummy packets

Shapingtimer

Algorithm Manager

De-queue Policy manager

−

packets in the right queue according to priority policies (such prioritisation is supported for performance reasons, but not described here due to space limitations). The function also notifies the algorithm manager about incoming packets, to provide input for adaptive algorithms. De-queue policy manager: decides from which queue a packet must be taken, based on queue priorities. Packet forming: at this step TFC header and padding are inserted. The actual padding size is managed by the Algorithm manager. Algorithm manager: is responsible for implementing the selected algorithm by triggering packet de-queuing and packet forming. It is activated when one or more packets must be sent from the associated SA. III. IMPLEMENTATION

Packet forming

IPsec

Figure 2: logical structure of the outbound TFC module

D. TFC architecture Figure 2 shows the logical structure of the components and interfaces composing the TFC module (showing only the outbound direction for simplicity). The architecture strictly follows the functional division of the TFC layer into two logical blocks, one being the modification of packet characteristics using basic TFC mechanisms, the other being the TFC control logic. As it is shown in Figure 2, basic TFC functions are triggered by the control logic for each packet through the Packet level control API. The control logic is configured through the Flow level API. Instead of handling the control logic as a monolithic module, we decided to detail it into two smaller blocks: the Security Association Manager (SA Manager), and the Algorithm Manager. The main difference between these blocks is the level of granularity they work on. The TFC SA Manager is responsible for interpreting ESP/TFC SA level configuration i) contained in user profiles, and ii) created based on higher layer activity. Based on these input, it has the task of setting up the Algorithm Manager and providing it with the necessary parameters. It also sets up SA level configuration data like parameters for dummy packet generation, padding parameters, queuing and de-queuing policies. Finally, the SA Manager notifies events, such as SA break down, to the upper layers. The Algorithm Manager, on the other hand, is the one that specifically handles the packets or, to be more precise, make use of the packet forming and traffic shaping functions in order to achieve the TFC requirements set by the TFC SA Manager. In Figure 2 the following logical components of our architecture are also shown: − Dummy packet generator: the function is responsible for the correct generation of dummy packets and for managing a queue of pre-built dummy packets. − Packet queuing: is a filter with the purpose of inserting

Our TFC implementation is developed inside the Linux Kernel 2.6 and is integrated with the IPsec framework therein deployed (other works rely on user-space implementations and thus suffer from performance drawbacks and are not integrated in the Linux IPsec protocol stack). Being developed as an IPsec sub-layer, the TFC protocol takes advantage of all the existing ESP functionalities (confidentiality, data integrity and authentication, as well as Security Association and policy management). The implementation also provides a “fallback” mode, in which case it restricts itself to the limited TFC functionality defined in ESP version 3, thus updating the Linux IPsec implementation to comply with the current standard. The Linux kernel provides several ways for the integration of a new protocol in the network stack: − Through the registration of the protocol number and of the respective protocol handling module in the protocol lookup table. Unfortunately this method triggers the processing of the new protocol only for inbound packets containing a next header field pointing to TFC; the protocol cannot be triggered in the outbound path through this mechanism. − By including a new layer between IP and upper layer protocols. Unfortunately there is no clear interface with the primitives of the IP layer, each protocol relying on IP, such as TCP, UDP, ICMP or IP (in the case of tunnelling) has its own entry point to the IP layer. − Through the XFRM framework [21], which is used to implement ESP and AH transformations, as well as the related Security Policy and Security Association databases. Here the problem lies in the details of the framework implementation, which does not allow for delaying packets. − Through hooks of the Netfilter framework [22] which explicitly provides support for delaying packets, but does not really compose a part of the networking stack. After analyzing the problem above, we decided for an implementation that exploits the fact that the TFC protocol, contrary to ESP or AH, does not need any state information at the receiver, neither out-of-band signaling to set-up common parameters for the SA. Therefore, we have

separated implementations for the inbound and the outbound path, providing a very light module using only protocol number registration for the inbound path, and a more complex module combining the use of the XFRM framework and Netfilter hooks for the outbound path. Our implementation for the outbound path is based on the scheme sketched in Figure 3. A packet queue is associated to an SA, and initialized when the SA is created. Data packets are intercepted through a custom-made TFC “hook” function. A hook is a well defined point that a packet has to cross in its way to the driver through the IP stack. Multiple functions can be registered to manipulate, discard or make other operations on a packet when this arrives to a hook (example of hooks are PRE_ROUTING, LOCAL_IN, FORWARDING). Our hook function is registered on the LOCAL_OUT hook. If no IPsec transformation or no respective SA is found for that packet, we leave it unmodified; otherwise the packet is taken from its normal processing in the Linux kernel and inserted into the appropriate queue. The en-queuing/de-queuing mechanisms are implemented through the standard socket buffer queue management functions available in the Linux kernel. The TFC control logic function is waken up by a timer. When the timer expires, the TFC function schedules the next timer and sends one or more packets, padded and wrapped into its TFC header, from the head of the packet queue back to the IP kernel stack for transmission. By suitably modifying this timer, different forwarding delays (or packet release times) can be achieved. If no packet is present, the TFC function can take the decision of sending a dummy packet. Since both our TFC queue and dummy generation are situated before IPsec encryption, dummy packets are sequentially encrypted similarly to data packets, and thus subject to an almost identical processing time. To further reduce the difference, we are also applying padding and including the TFC header in dummy packets as well. This prevents an attacker (situated near the source) from identifying dummy packets based on different inter-arrival times of the packets.

Figure 3: TFC Linux kernel implementation

802.11g

AP

B Ethernet 100BASE-T

A C

Figure 4: Experimental test setup

IV. INITIAL EXPERIMENTAL ASSESSMENT To assess the functionality of the TFC protocol and its proper implementation, a test bed composed of three computers (Acer TravelMate 3220WXCi notebooks) and an Access Point (D-Link DWL-900AP+) were setup, as shown in Figure 4. Computer A was used as an application client and B as a server, while C modelled the eavesdropper on the wireless communication (802.11g) between A and the AP. C was running a Wireshark version extended with a plug-in to decode the TFC header. During the evaluation several TFC algorithms (constant packet size padding, CBR, random padding) triggering different basic TFC mechanisms were activated, while different application level protocols (ping, HTTP, SSH, VoIP) were tested. Separate SAs were set-up in both directions of the traffic. First we demonstrate a case of traffic fingerprinting. It can be easily recognised in Figure 5 how the traffic patterns generated by two SSH handshake attempts (before typing the password) resemble to each other.

Figure 5: SSH connection fingerprint (2 examples)

Such traffic patterns (of SSH, of other protocols as well as of specific actions) are easily recognised by traffic analysis techniques, as the ones proposed in recent literature [1][3][4]. In Figure 6 we visually demonstrate how some selected TFC algorithms can change such traffic patterns. The first algorithm adds limited overhead but clearly shows to be ineffective in hiding the SSH characterizing spikes. The other algorithms instead appear more effective in protecting the traffic pattern, but clearly increase the traffic overhead (especially in the third case where unobservability is gained only at the severe expense of continuous traffic masking). While the difference between the original and the modified pattern can clearly be seen, the mathematical quantification of the effectiveness of a traffic masking approach in hiding the information about the original traffic pattern requires a more sophisticated statistical analysis, which is out of the scope of this paper and object of current research work.

Ongoing work is targeting two complementary goals. First, an anonymous routing platform is being developed on top of IPsec/TFC to allow multi-service support. Second, detailed performance/privacy trade-off studies are being carried out to determine low-overhead traffic masking algorithms minimizing the network overhead while providing sufficient privacy protection. REFERENCES [1]

[2]

[3]

Figure 6: SSH connection masqueraded: (top) padding to fixed size (500 bytes) and delaying to fixed timeslots (every 5ms); (middle) padding to random size (500 to 900 bytes) and delaying to fixed timeslots (every 10ms); (bottom) adding dummy packets (every 10ms) and padding to random size (100 to 900 bytes)

[4]

Another typical case of traffic analysis is the recognition of VoIP flows or the characterization of VoIP applications [2]. Figure 7 shows the trace of a VoIP conversation (using the Ekiga application [23]) and its pattern after random padding and a small random delay is applied. Ekiga uses the GSM encoder and RTP/RTCP protocol to support the media stream and its control. Such a simple TFC approach can easily render packet size or packet size variance based analysis techniques useless. Further modification of delays would also confuse more advanced techniques, but with a QoS price to pay due to increased jitter.

[6]

[5]

[7]

[8]

[9] [10]

[11]

V. CONCLUSIONS This work presented the architecture and implementation of a Traffic Flow Confidentiality (TFC) approach integrated in IPsec, devised to mask traffic and protect it from statistical traffic analysis attacks. A TFC control module has been designed and developed to enforce basic per-packet treatments (including packet padding, fragmentation, dummy packet generation and management, and artificial alteration of the forwarding delay) as well as masking algorithms (e.g., CBR-ize traffic, or shape it according to other pre-defined patterns).

[12] [13]

[14]

[15]

[16]

[17] [18] [19] [20] [21]

Figure 7: VoIP conversation: RTP stream with GSM encoding (top); the same masqueraded by random padding (bottom)

[22] [23]

M. Crotti, F. Gringoli, P. Pelosato, L. Salgarelli, “A statistical approach to IP-level classification of network traffic”, the 2006 IEEE International Conference on Communications, 11-15 Jun. 2006. T. Okabe, T. Shinuzo, T. Kitamura, “Statistical Traffic Identification Method Based on Flow-Level Behavior for Fair VoIP service”, 1st IEEE ws. on VoIP Management and Security: VoIP MaSe 3rd April 2006. A Hintz, “Fingerprinting Websites Using Traffic Analysis Privacy Enhancing Technologies”, second International Workshop, PET 2002 San Francisco, CA, USA, April 14-15, 2002. G. D. Bissias, M. Liberatore, D. Jensen, B. N. Levine, “Privacy Vulnerabilities in Encrypted HTTP Streams” Privacy Enhancing Technologies: 5th Int. Ws, PET 2005, Cavtat, Croatia, May 30, 2005. D. X. Song, D. Wagner, X. Tian, “Timing analysis of keystrokes and timing attacks on SSH”, in Tenth USENIX Security Symposium, 2001. B. Canvel, A. Hiltgen, S.Vaudenay, M. Vuagnoux, “Password Interception in a SSL/TLS Channel”, CRYPTO2003 August 17-21, 2003, Santa Barbara, USA. S. Vaudenay, “Security Flaws Induced by CBC Padding - application to SSL, IPSEC, WTLS”, in Advance in Cryptology EUROCRYPT02 Amsterdam, Netherlands 2002. T. Kohno, A. Broido, K. C. Claffy. “Remote physical device fingerprinting”, in IEEE Symposium on Security and Privacy, pages 211–225. IEEE Computer Society, 2005. B. Timmerman, “Secure Dynamic Adaptive Traffic Masking”, in New security paradigms workshop, 1999. Y. Guan, X. Fu, D. Xuan, P. Shenoy, R. Bettati, W. Zhao, “NetCamo: Camouflaging Network Traffic for QoS-Guaranteed Mission Critical Applications”, IEEE Transactions on System, Man, and Cybernetics, Special Issue on Inf. Assurance, Vol. 31, No. 4, pp. 253-266, July 2001. X. Fu, B. Graham, R. Bettati, W. Zhao, D. Xuan, “Analytical and Empirical Analysis of Countermeasures to Traffic Analysis Attacks”, ICPP 2003: 483-492 K. Streff, A. Rajagopalan, X. Fu, “ABC: Adaptive Bank-Transaction Camouflaging Systems”, ICIW 2006 G. Danezis, R. Dingledine, N. Mathewson, “Mixminion: Design of a Type III Anonymous Remailer Protocol”, proceedings of the 2003 IEEE Symposium on Security and Privacy, May 2003. R. Dingledine N. Mathewson, P. Syverson, “Tor: The SecondGeneration Onion Router”, in the Proceedings of the 13th USENIX Security Symposium, August 2004. M. Rennhard, B. Plattner, “Introducing MorphMix: Peer-to-Peer based Anonymous Internet Usage with Collusion Detection”, In the Proceedings of the Workshop on Privacy in the Electronic Society (WPES 2002), Washington, DC, USA, November 2002 M. J. Freedman, R. Morris, “Tarzan: a Peer-to-Peer Anonymizing Network Layer”, Proc. of the 9th ACM Conference on Computer and Communications Security (CCS’02), Washington, DC, Nov. 2002. S. Kent, "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. P. Eronen, “IKEv2 Mobility and Multihoming Protocol (MOBIKE)”, RFC 4555, June 2006 S. Kent, K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. T. Dierks, E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. K. Miyazawa, M. Nakamura, “IPv6 IPsec and Mobile IPv6 implementation of Linux”, Linux Symposium 2004, Ottawa, Canada, July 20-24 , 2004 Netfilter/iptables project homepage: http://www.netfilter.org/ Ekiga (former GnomeMeeting) homepage: http://www.ekiga.org/