A Framework for the Implementation of Secure Bare-Based Web-Email System

DOI 10.7603/s40601-014-0018-4 A Framework for the Implementation of Secure Bare-Based Web-Email System Patrick Appiah-Kubi, Anthony Tsetse, and Alae Loukili Received 29 Jun 2015 Accepted 27 Jul 2015 Abstract - Webmail systems have being developed for different OS-based platforms. These OS-based systems present their own benefits and treats. Framework and white papers for developing these systems are available but there is no specific framework available for the implementation of such systems on Bare PC. Implementation of such systems on a Bare PC poses daunting challenges and innovative opportunities that are revolutionary in server designs. Building such systems for security could even be more challenging. Secure Webmail systems are complex, large and require intricate components to develop. As a result, a lean system was developed for this research. The lean concept also helps to build small protocol suite, intertwining of protocols, limited requirement space, simple user interfaces and minimal design options. The paper provides a detail framework for the design and implementation, experimental setup and the results of experiments conducted. Performance is evaluated by measuring the processing time, throughput, the CPU Utilization and load distribution. The results show that the performance of the Bare PC Webmail server is significantly better than that of the OS-based servers. Keywords-Bare PC; Application Object; HTTP; PHP parser; TLS; SMTP; Operating system. I. INTRODUCTION Webmail is a web-based email service that allows users to access their email through a web browser instead of using desktop email clients (such as Microsoft Outlook, Pegasus Mail, Mozilla Thunderbird and Eudora). It allows users to access their email account from any Internet enabled device located anywhere, unlike the applicationbased email system. A conventional secure webmail system uses protocols such as simple mail transfer protocol (SMTP), post office protocol (POP3) or internet message access protocol (IMAP), hypertext transfer protocol (HTTP) and transport layer security (TLS), to exchange messages. These protocols provide independent services to ensure email exchanges. Figure 1 presents a pictorial illustration of email exchanges between the various email services. user agent HTTP/TLS Request Web server / Mail Agent SMTP/POP3 Figure 1: Conventional Email Exchanges mail server SQL Queries Database In situations where dynamic HTTP requests are sent to the Webmail Server for processing/parsing coupled with a secured request using static or dynamic TLS, the complexity of Webmail system increases significantly. The design of the Bare PC-based web-email system was as a result of experiences gained in developing the Bare PC TLS, HTTP, SMTP and POP3 protocols. A Bare PC Web server interfaces with any commercial client adhering to the client requests and their interfaces. It does not have any control on the client user interfaces. The Bare PC webmail system developed is user friendly to Bare PC environment as the functionality and complexity can be dealt with at the server level. This is because; webmail system servers generate and serve all Web pages to the client thus allowing the designer to control the design of the system. The Bare PC webmail architecture is based on threading techniques, delay/resume lists, and task stack DOI: 10.5176/2251-3043_4.3.333 71

mechanisms to provide efficient memory utilization and process control. It contains its own data execution knowledge and control, and does not require any other software support to run. Currently, the Bare PC Webmail system run on Intel Pentium 4 (or above) based PCs and only requires common general-purpose hardware including USB-based bootable devices, network interface cards, and USB-based persistent storage. The system is also not vulnerable to attacks targeting an underlying OS. Bare PC applications are built to be secure since all underlying OS vulnerabilities are eliminated at design level. The TLS protocol added to the design enhances security when sending and receiving messages. Since a Bare PC server application is self-supporting, it is unlike its OS-based counterpart that relies on services provided by the OS. For example, a Bare PC server application contains lean versions of the necessary protocols, manages memory, schedules tasks on the CPU, and directly accesses the underlying hardware. Furthermore, the application layer and transport layer protocol code is intertwined within the code for the server application. There is no socket interface for applications in a Bare PC server, and the intertwined parts of the code and the underlying task structure can differ from application to application. Protocol intertwining reduces inter-layer communication overhead compared to a conventional OSbased TCP/IP protocol stack, but complicates the design and implementation of the server. Bare PC applications do not use a local disk (they only require detachable mass storage). The application directly communicates with the hardware (in this case an X86-based CPU). This approach can be used to build pervasive devices, gateways, routers, or sensors that host small efficient bare PC applications. The paper is organized as follows, section I is the introduction, II covers related work, III covers architecture and design, IV covers experimental analysis and V is the conclusion. II. RELATED WORK The first attempt to minimize Operating systems (OS) functionality was proposed in the Exokernel[1][2] architecture where minimum OS functionality was used to obtain core processes such as kernel system processes. Studies such as Microkernel, OS-Kit[3], Bare-metal Linux, IO-Lite[4], Tiny OS[5] and other approaches have tried to reduce the interaction of OS or bypass OS to gain efficiency in the system. In [6], Linux is used to enable direct communication with the hardware by reducing the OS reliability. More recently, sandboxing techniques on the x86 systems[7] have extended OS kernels allowing applications to run guest plug-ins on the host OS. However none of the above proposed techniques propose a complete elimination of all OS support except for the Bare PC paradigm. The strength of Bare PC applications is derived from its simplicity, smaller code, design by obscurity, design for longevity, and inherent security. The Bare box can be used to run a variety of applications. The Application Object (AO) is self-contained and it belongs to an owner, which can be made secure at the AO level. As the AOs are application centric, it does not require all OS components as needed in today s OS. Only necessary hardware interfaces and controls are included in the AO thus making the AO small in size, simple in design and development. An AO may constitute a single application such as Webmail server or it may consist of composite applications including: Webmail server, Web Browser and a Text-editor. Applications like the Web server[8], Email Server[9][10] VoIP[11][12] and TLS on web server[13] have been built on Bare PC and these applications demonstrated significant improvements in performance compared to other commercial systems. These applications uncovered the unique features of the Bare PC architecture and served as the bases for the design and implementation of the Bare PC Webmail Server. Current Webmail systems such as Atmail[14], Petmail[20], MailTraq[15], Axigen[16], Afterlogic[17], Squirrelmail[18], Facemail[19], icewarp[21], Hexamail[22], all focus on OS-based systems. Some of these systems are designed for high performance, while others such as Cisco s Webex[23] are designed for high reliability and availability. Techniques to improve performance of the Open Webmail system are discussed in [24]. Email server architecture, which is based on a spam workload and optimized with respect to concurrency, I/O and IP address lookups, is shown to significantly improve performance and throughput. The design and implementation of an email pseudonym server providing anonymity to reduce server threats is capable of reducing risks due to OS-based vulnerabilities. Some performance and design details of Webmail system is described in [24]. The security aspects of Webmail systems have been studied by many authors [25][26]. Webmail systems use HTTPS/TLS protocol to protect email messages in transit. However, all existing TLS-capable Webmail systems are OS based, and there is no TLS-capable Webmail system that runs on a Bare PC. There are alternate approaches to email security. S/MIME [25] provides encryption, authentication, message integrity and non-repudiation for MIME messages exchanged between users (i.e., end-toend). The design and implementation of a secure email 72

system that provides encryption and signing, and additional features such as elimination of spam and prevention of harmful attachments is described. The implementation of a secure Webmail system that uses CallerID for access is discussed in [26]. Operating System (OS-based) systems are based on some sort of centralized resource manager or controller to provide hardware abstractions to applications. The Bare PC previously referred to as dispersed Operating Systems computing (DOSC)[27] proposes an extreme end of the spectrum in OS for building computer applications where there is no centralized resource manager or controller running in the machine. Applications[28] in Bare PC directly communicate with hardware (no need for abstraction layers) and the computer is made Bare (no hard disk, no resident software, except BIOS). The Bare PC approach is application centric and provides full control to the Bare PC programmer. Bare PC applications referred to as application object (AO)[28] contain all the necessary application, data execution knowledge, and control. There is no need for the AO to depend on any other software or vendor specific products. The AO is built using a single programming language and works on a given CPU architecture base such as X86. These AOs can also be written to work with any other CPU architectures. III. A. Architecture ARCHITECTURE AND DESIGN The server architecture is supported by common general-purpose hardware including USB-based bootable devices, network interface cards, USB-based persistent storage, and Intel x86 based PCs. However, this server can be extended to run on other Intel processor architectures. The internal architectural design is based on threading techniques, delay/resume lists, and task stack mechanisms to provide efficient memory utilization and process control. However, the architecture does not make use of any components of an OS or any other vendor software. Likewise, the compilation and execution of the Bare PC application object for the Webmail server does not make use of any system or API libraries of the compiler which would require an OS. The Bare PC approach only uses few BIOS function calls to invoke the timer, and reading device addresses from the Intel Hub Controller. Eventually, these BIOS calls and direct hardware interfaces can be driven to CPU to provide an AO execution. All other interrupts are managed by the AO as software interrupts or direct hardware interfaces. POP3 Task Pool 12 Network 19 20 NIC Driver 18 N I C Tasks Stacks 17 Delay List Resume List SMTP Task Pool 11 22 STD RCV Task 5 6 TCP Table (TCB) (Migratory Entries) HTTP Task Pool 10 7 8 ETH POP3 Object SMTP Object HTTP Object TLS Object Figure 2: Bare PC Webmail System Architecture Figure 2 shows the architectural design of the Bare PC Webmail server. For referencing purpose, numeric labels are assigned to items within the figure. The server is initiated on a Bare PC by a boot program (1) which is read from a USB-bootable device. The initial sector contains a bootstrap loader which loads the menu program (2), which then loads the AO. The AO starts by initializing various data structures, parameters, tasks, and objects. Control is then passed to the Main Task (3). The basic Bare PC data structures used by the Main Task include a Delayed List (16), Resume List (15) and a Multiplexor mechanism (4) that switches between Received Tasks (20) and Resume List Tasks (HTTP, SMTP, POP3, TLS) and selects a running task (13). This running task can be suspended and returned to the Delayed List (16) when it is not being run. The Main Task checks for delayed tasks, whenever it is free and place them in the resume list. When a response arrives for a Delayed List task, a Resume () brings the Delayed List task into the Resume List. A TCP Table (TCB, 17) is used to store relevant information derived from the headers of TCP, IP and Ethernet messages (21). To communicate directly with the host 14 IP TLS Task Pool 9 16 TCP 13 M U X 15 Main Task Menu / Loader Boot Program Running Task 4 3 2 1 21 Resume 73

Network Interface Card (NIC, 18), a Bare PC NIC driver was written (19). Four components were created within the Bare PC Webmail application to handle all Webmail functions. These are a POP3 Object (5) to retrieve email messages from an email server, SMTP Object (6) to send emails messages from clients to the server, TLS Object (8) to encrypt all messages being transmitted and an HTTP Object (7) to interface with web clients. At initialization, a task pool of POP3 (12), SMTP (11), TLS (9) and HTTP (10) objects are created along with their associated TCB table entries for use by the server application. When a client request arrives, one of these objects based on an HTTP, POP3 or SMTP request is placed in the Resume Task List (15), and an active status flag is set within its associated TCB entry. The TCB entry contains all of the unique data attributes associated with the object, and its executable state information. When the task is complete, it is returned to its appropriate task stack (14) so that it can be reused again. The active flag in the associated TCB entry along with associated data fields are then reset. The Bare PC architecture for Webmail systems is novel and unique in many respects. The Webmail application only performs functions that are truly intended in its design. The scheduling mechanism is optimized for its function, and it can be claimed that it is an optimal solution for this application. The RCV task (20) receives packets and processes them in a single thread of execution without any interruptions or process swapping until the status is updated in TCB. The HTTP, TLS, SMTP or POP3 tasks do the same when it is ready to run. The suspension place and time is determined by the AO programmer at the program time and it is implemented in the code. The AO programmer will only suspend a task if it is waiting for an event. When a task is complete, the same task will be reused without creating new tasks. All task pools are statically created by the AO programmer. The novelty of this server approach stems from the notion that the process execution knowledge and control are shifted from OS environment to AO programmer environment thus making the application self-controlled, self-executed, and self-managed. The system always runs a RCV task or any of the tasks thus making the scheduler simple and its mechanism first come first serve. However, if the suspended delayed task expires in the Delayed List, it moves to the Resume List and follows the first-in-firstout (FIFO) priority. There is no need to prioritize any tasks in this model as all client requests will be given equal priority as they are ordered with respect to their arrivals. The Webmail server architecture is a design for optimization rather than enhancing performance after the design. This approach can be used throughout any Bare PC applications, which are very difficult to achieve in a centralized OS based computing architecture. B. Design considerations The design of the Bare PC Webmail server was a very daunting and challenging task. The first task was to understand the functionality of the entire Webmail system and as such, one Linux-based and one windows-based servers were installed and studied carefully. The design also avoids the use of any OS-based features and kernels, and creates an application, which will run on a Bare PC. The design of the Bare PC webmail application was based on state transition diagrams. The SMTP, POP3, TLS and HTTP protocols were intertwined to allow the execution of the specified function in the message. Figure 3 illustrates the intertwining of the protocols and the message exchanges between a client and a server to establish and close a connection. As shown in the figure, when a client request a TCP connection to sever, it sends a SYN request and wait for an SYN-ACK and then sends an ACK. After the ACK is sent, the state moves into the TCP ESTAB state where protocols can send and receive messages. Figure 4 shows the state transition diagram for the TLS handshake process between a client and a server. Here the client request a TLS connection to the server after it has established TCP connection to the server. When the server receives the request, it must validate the client by sending the certificate and key information to the client. Once the client is validated and the keys for encryption are established the client and server move to the TLS-ESTB state, where encrypted messages can be exchanged. Figure 5 shows the state transition diagram for the SMTP connection establishment process. After the client and server establish TCP connection, they must move to the SMTP-WESTAB so the server can validate the client before messages can be exchanged. Figure 6 shows the state transition diagram for the POP3 connection establishment process. After the TCP connection establishment between the client and server, they must move to the POP3-WESTAB state, so that the server can validate the client before message exchanges. 74

Figure 6: State Transition Diagram for POP3 Connection Establishment Figure 3: State Transition Diagram for Connection Establishment and Closure IV. EXPERIMENTAL ANALYSIS A. Experimental Setup A Bare PC environmental setup was established as shown in figure 7 below. All switches used in the setup were gigabit switches. The clients ran Windows 7 with Firefox and Internet Explorer as the web clients. The OSbased servers ran Windows 2012 or Linux (CentOS / Fedora). The routers were Linux based. All machines were Dell OptiPlex GX520s. OS-based Webmail system details are as follows: Atmail Server 6.20.4 (Linux), Icewarp Server 11.2 (XP), and Squirrelmail Server 1.4.22 (Linux). A legacy client PC located 50 miles away with about 30 router and firewall hops from the Bare PC network was used for the WAN measurements. The Visual Trace Route tool verified the hop count during the tests, which were performed in a contiguous time period. Figure 4: State Transition Diagram TLS Handshake Figure 5: State Transition Diagram for SMTP Connection Establishment Figure 7: Experimental Setup 75

B. Results Analysis Different test scenarios were run and captured with Wireshark analyzer and web stress tool. The final results are analyzed in this section. Figure 8 shows the measure of CPU load over a time period, using TLS and Non-TLS enabled webmail systems on Bare PC, Windows and Linux as captured on web stress tool. As shown in the figure the Bare PC systems (i.e. Secure and non-secure webmail systems) start with high CPU utilization and linear out as the time increases. This is due to saturation of request when the times are high. The Linux based systems seem flat throughout but the windows systems increase their CPU utilization, when the time increases. The average waiting time for a user to receive a response from the server, when the server is under heavy load was captured with web stress tool and analyzed in figure 10 below. We see that the wait time for both Bare PC systems (i.e. secure and non-secure is relatively low under 100 msec as compared to the Linux systems which are about 100 msec. The Windows systems however have high wait times of 300 to 500 msec. Figure 10: Waiting time for response when servers are under stress Figure 8: Server CPU load over time The server bandwidth or throughput which is measured in bits/second was captured with web stress tool over time and analyzed in figure 9 below. As shown, the Bare PC systems increase exponentially and become flat after 5 seconds. This corresponds to the rate of usage as shown in figure 8. The Linux and Windows systems also increase exponentially to about 70Kbit/sec and become flat after 5 seconds, thus corresponding to the load on the server. Figure 11 shows the server response rate of the server. A higher response rate corresponds to lower wait time for the user. As we can see, the Bare systems have high response rates which clearly justifies the small wait time on the part of the user. The Windows systems have the lowest response rate and therefore a higher wait time for the users. The total processing time for a single complete request of 200 bytes file size is presented in figure 12 below. The Bare systems have low processing time because they take advantage of the threading techniques, single thread of execution technique, higher load distribution to process the request much quickly. The Linux systems have the second best times as compared to the Windows systems. Server Response Rate 0.2 0.18 0.16 0.14 0.12 0.1 0.08 0.06 0.04 0.02 0 Server Response Rate Squirrelmail-Linux Atmail-Linux Cent Icewarp-Win Fedora OS No-TLS TLS-Enabled Bare PC Figure 9: Server throughput over time Figure 11: Server response rate for request 76

Figure 13 shows the processing times for a single inbox request over a WAN environment. Again the Bare systems show very low processing time as compared to the Linux and Windows systems. However the processing times Linux and Windows systems seem to be very close. This could be attributed to the multiple hop counts and the Linux systems inability to leverage on processing power to reduce the time. Figure 14 shows the processing times in seconds of a single 120,000 bytes attachment over a WAN for all systems. Bare PC is still lower than the other systems by a margin of about 46% average for all the other systems. Processing Time(sec) 0.5 0.45 0.4 0.35 0.3 0.25 0.2 0.15 0.1 0.05 0 Squirrelmail-Linux Fedora Processing Time Atmail-Linux Cent Icewarp-Win OS No-TLS TLS-Enabled Bare PC Figure 14: Time to process a single 120,000 bytes message on a WAN Figure 12: Time to process a single request Figure 15: Time between the first ACK after request and first Data sent Figure 15 shows the time captured when the first ACK for the request comes in the time it takes the server to send the first data packet. Bare has low processing time as compared to the other systems. V. CONCLUSION Figure 13: Time for processing a single inbox request on a WAN In this paper we discussed a framework for the design and implementation of a secure Bare PC web-mail system. This framework can serve as fundamentals to the development of any reliable system based on the Bare PC paradigm. Results from the experimental analysis conducted indicate that Bare PC applications perform better than all the other OS-based systems in terms of throughput, processing time etc. The webmail systems does not use file system as seen in regular webmail applications. It only makes use of physical memory. A file system has been developed for Bare PC applications, but was not included in this implementation since it has not being validated. Future work on the webmail system will 77

include the implementation of a file system and the use of IMAP4 instead of POP3. REFERENCES [1] D. R. Engler, The Exokernel Operating System Architecture, MIT, Oct. 1998. [2] D. R. Engler and M. Kaashoek, Exterminate all operating system abstractions, in 5th Workshop on Hot Topics in Operating Systems, Orcas Island, WA, 1995. [3] The OS Kit Project, The OS Kit Project. [Online]. Available: http://www.cs.utah.edu/flux/oskit/. [Accessed: 15-May-2015]. [4] V. Pai, P. Druschel, and W. Zwaenepoel, IO-Lite: A Unified I/O Buffering and Caching System, Vol.18 (1), ACM, February 2000, pp. 37-66., ACM Transactions on Computer Systems, vol. 18, pp. 37 66, Feb. 2000. [5] Tiny OS Community Forum, Tiny OS. [Online]. Available: http://tinyos.stanford.edu/tinyoswiki/index.php/tinyos_documentation_wiki. [Accessed: 25- May-2015]. [6] B. Ford, M. Hibler, J. Lepreau, R. McGrath, and P. Tullman, Interface and execution models in the Fluke Kernel New Orleans, LA, February 1999, pp. 101-115., in The third Symposium on Operating Systems Design and Implementation, New Orlean, LA, 1999, pp. 101 115. [7] B. Ford and R. Cox, Vx32: Lightweight User-level Sandboxing on the x86, in USENIX Annual Technical Conference, Boston MA, 2008. [8] L. He, R. K. Karne, and A. L. Wijesinha, The Design and Performance of a Bare PC Web Server, International Journal of Computers and Their Applications, vol. 15, pp. 100 112, Jun. 2008. [9] G. Ford Jr, R. K. Karne, A. L. Wijesinha, and P. Appiah-Kubi, The Design and Implementation of a Bare PC Email Server, in 33rd Annual IEEE International Computer Software and Applications Conference, 2009. [10] G. Ford, R. K. Karne, A. L. Wijesinha, and P. Appiah-Kubi, The performance of a Bare Machine email server, in 21st International Symposium on Computing Architecture and High Performance Computing, 2009. [11] G. H. Khaksari, A. L. Wijesinha, R. K. Karne, L. He, and S. Girumala, A Peer-to-Peer bare PC VoIP Application, in IEEE Consumer and Communications and Networking Conference (CCNC), Las Vegas, 2007. [12] G. H. Khaksari, A. L. Wijesinha, R.. Karne, L. He, and S. Girumala, A Peer-to-Peer Bare PC VoIP Application, in IEEE Consumer and Communications and Networking Conference, Las Vegas, 2007. [13] A. Emdadi, R. K. Karne, and A. L. Wijesinha, Implementing the TLS Protocol on a Bare PC, in 2nd International Conference on Computer Research and Development (ICCRD), 2010. [14] Atmail-Linux Webmail Server. [Online]. Available: www.atmail.com. [Accessed: 05-Jun-2015]. [15] Mailtraq email server-the complete email server. [Online]. Available: www.mailtraq.com. [Accessed: 10-Jun-2015]. [16] Axigen Email Sevrer. [Online]. Available: www.axigen.com. [Accessed: 23-May-2015]. [17] Afterlogic Webmail Server. [Online]. Available: www.afterlogic.com. [Accessed: 20-May-2015]. [18] SquirrelMail Webmail. [Online]. Available: www.squirrelmail.org. [Accessed: 15-May-2015]. [19] E. Lieberman and R.. Miller, Facemail: showing faces of recipients to prevent misdirected email, in The 3rd symposium on Usable privacy and security, Pittsburgh, Pennsylvania. [20] Petmail Webmail Server.. [21] IceWarp Mail Server. [Online]. Available: www.icewarp.com. [Accessed: 20-May-2015]. [22] Hexamail Webmail Server. [Online]. Available: www.hexamail.com. [Accessed: 06-May-2015]. [23] Cisco WebEx Mail: High availability design for your most mission critical application. Tech Republic. [Online]. Available: http://www.techrepublic.com/resourcelibrary/whitepapers/cisco-webex-mail-high-availability-designfor-your-most-mission-critical-application/ [Accessed: 06-May- 2015]. [24] C. Tung and S. Tsai, Tuning Webmail performance-the design and implementation of Open Webmail. [Online]. Available: www.openwebmail.org. [Accessed: 15-May-2015]. [25] P. Noiumkar and T. Chomsiri, Top 10 Free Webmail Security Test Using Session Hijacking, in International Conference on, Convergence Information Technology, 2008, pp. 486 490. [26] A.. Tomar, S. Chaudhari, J. Patil, and A. Rawat, Implementation and Security Analysis of a CallerId Augmented 2FA Setup for Secure Web-mail Access pp. 346-348., in The 2010 IEEE International Conference on Advances in Communication Network and Computing. (CNC), 2010., pp. 346 348. [27] R.. Karne, K. V. Jaganathan, and T. Ahmed, DOSC: Dispersed Operating System Computing, in 20th Annual ACM Conference on Object Oriented Programming, Systems, Languages, and Applications, Onward Track, San Diego, 2005, pp. 55 61. [28] R.. Karne, Application-oriented Object Architecture: A Revolutionary Approach., in 6th International Conference, HPC Asia, 2002. AUTHORS PROFILE Dr. Patrick Appiah-Kubi is an Assistant professor and IT program coordinator in the Electronics and Computer Engineering Department at Indiana State University, USA. He previously worked as a lecturer in the Computer and Information Sciences Department at Towson University. He also worked as a systems engineer and IT consultant at MVS Consulting in Washington DC before joining Towson University. He has a Doctorate in Information Technology from Towson University, Master s in Electronics and Computer Technology from Indiana State University, and a Bachelor s in 78

Computer Science from Kwame Nkrumah University of Science and Technology, Ghana. His research interests are in bare machine computing systems, networks, Cloud Computing, Big Data and mining, Distributed Databases and security. Dr. Anthony K. Tsetse received his B. S. Computer Science degree from the Kwame Nkrumah University of Science and Technology, Kumasi, Ghana.He earned his M.S. Communication and Media Engineering degree from the Offenburg University of Applied Sciences Germany and M.S. in Information Technology degree from the IT University of Copenhagen, Denmark. He graduated from Towson University, USA with a Doctor of Science degree in Information Technology. Anthony is currently an Assistant professor in the department of Computer Information Systems at the State University of New York Fredonia. His current research interests include Bare Machine Computing, Network Performance analysis, Cloud computing, Network security and Data Analytics. Alae Loukili holds a doctorate in Information Technology and a Masters degree in Computer Science from Towson University. He also holds a Masters degree in Electrical Engineering from l' Ecole Nationale Supérieure d'electricité et de Mécanique de Casablanca. He is currently an Assistant Professor in the Department of Mathematics and Computer Science at Ohio Dominican University. His research interests are in computer networks and data communications, wireless communications, and bare machine computing. This article is distributed under the terms of the Creative Commons Attribution License which permits any use, distribution, and reproduction in any medium, provided the original author(s) and the source are credited. 79