Computer Networking and Management - Case Study Example

Computer Networking and Management Project Supervisor's Table of Contents Table of Figures 1 Intranet Infrastructure Description An Engineering college intranet is considered, with the following geographical and user population: College consist of four departments, each is housed in a separate building. There is a separate Engineering library building and a one-floor data center. Each departmental building accommodates all its own administrative staff, faculty, and labs. All departmental buildings are located on the same campus, within a one square Km area. A dedicated, one-floor, facility houses all college-wide servers and external network connectivity appliances, as well as the network management center (NMC). Within each department, there are four user classes: Public work area, with 150 fixed desktops and another 100 free seats with wireless network access for students with laptops. Admin offices, with an average staff of 15 per department. Faculty offices, with an average of 25 offices per department. Specialized labs, whose number ranges from one to four labs in each department, with each lab containing about 20 workstations. Engineering library Operating Systems Three operating systems are in use, whose distribution is provided in Table 1. Note that servers are treated separately in Section 1.3. Public work areas 80% Windows XP, 20% Linux Admin offices All Windows XP Faculty offices Windows XP, Linux, Sun Solaris (depending on need and preference) Specialized Labs Windows XP, Linux, Sun Solaris (depending on application) Engineering Library Windows XP Table : Operating systems distribution The rationale for the operating systems installed is as follows: Windows XP is a stable and well tried Windows release that has been in operation for a number of years. It is a common dominating factor that is in use by all user categories for all office and some research functions. Some Linux PCs are available in public work areas, faculty offices, and labs for purpose of either personal preference or the need for certain research applications and tools. Solaris workstations are accommodated in some faculty offices and labs for the same reason as that of Linux PCs. VLAN configurations at the data center core switch enable functional areas within each department to operate as independent LANs regardless of their physical locations. Internet-enabled Client Applications The following typical applications are allowed by the security management team to access the Internet: 1. Web browsers (IE 7). 2. Email client (Outlook 2007). 3. Skype client; used for voice chat, instant messaging, video conferencing, and low-cost Internet telephony. These applications were found essential to facilitate immediate contact and collaboration across to other universities and research institutions. No other network applications are allowed access to the Internet. The above Internet clients operate at designated TCP ports, which are open but monitored and occasionally audited though the firewall, to ensure compliance with security and IT access policy set forth by the campus network management. Any other applications requiring access to university wide intranet resources achieve that through a web interface and therefore do not require having arbitrary ports open. Figure : screen shot of web browser, email client, and IM/IPT clients Servers Servers, central security appliances, and edge network appliances are all housed in a secure one-level data center, located within the same campus area. Servers are connected to the main access router via a 10Gbps optical Ethernet. Table 2 illustrates the server distribution, platforms, and functionality. Web server (Linux) 1 central server Hosts the intranet portals and internal applications Mail server (Exchange over Windows 2003) 1 central server Hosts all email accounts and archives Domain Controller (Windows 2003) 1 central server Manages DNS, DHCP, and Active Directory Antivirus server (Linux) 1 central server Manages AV updates and reporting/logging IPBX server (Linux) 1 central server Implements IP based campus-wide telephony with gateway to other university colleges, the public network, and the Skype network Database server (Solaris) 1 central server Provides backend database platform to applications CAD and other high-resolution design application servers (Solaris) 1 for each department Platform for each department to install and access graphics demanding design application from within their lab environments Print servers (Linux) 2 servers Manage shared printing jobs in shared work areas, library, and department buildings Table : Listing of servers supporting college network applications Network Appliances Network appliances include: Network interface cards (NICs); installed in desktops to connect to the LAN. Wi-Fi transceivers; may be built-in or externally connected via USB, to access a wireless LAN. Hubs; used to connect two or more Ethernet segments at the physical layer. Intelligent, or manageable hubs, allow network administrators to monitor their traffic, configure and control port accessibility, and monitor traffic by a number of parameters. LAN (layer 2) switches; used to connect two or more Ethernet segments at the media access layer, where every segment becomes a closed collision domain. Layer 2 switches also are used to logically separate IP addresses on their ports into independent functional virtual LANs (VLANs), where frame broadcast is restricted to each. Configuring VLANs has performance advantages (due to limiting contention and simplifying trouble shooting) and security advantages (since a malware infection can only propagate at the MAC layer within one VLAN rather than all IPs. Routers; used to interconnect separate IP networks, as well as connect an intranet to the Internet. The network is setup as follows: Within each department, there are (reference can be made to Figures 2 and 3): One shared work area consisting of PC-equipped and free seat locations, all covered by a Wi-Fi hotspot. One or more labs, each containing a number of high-performance bandwidth-demanding workstations, interconnected via a Gigabit Ethernet. A number of faulty and staff offices, each with one Ethernet outlet, interconnected via a Gigabit Ethernet. The three Ethernet are connected to a four-port layer-2 switch, whose fourth port supports a 10 Gbps fiber Ethernet. All Ethernet cables are terminated at a layer-2 switch that acts as the edge device for the department. The Engineering library, being the fifth building, is covered by two bridged 802.11n Wi-Fi hotspots that cover an area of about 200 square meter each at maximum bit rate of 248 Mbps, linked to the data center by another Gigabit fiber Ethernet. The datacenter houses the 12 servers detailed in Table 2, which are interconnected together with a redundant core layer-2 switch via 1 10 Gbps optical Ethernet. The core switch divides the user groups into VLANs, which are totally isolated broadcast domains, for better performance, manageability, and security. For example, the labs within each department can be configured into a single VLAN that includes their related servers at the data center, each departmental (as well as the library's) public work area is configured as another VLAN, administrative and faculty staff offices are configured each as a VLAN that includes servers they require. Note that a server can be a member of more than one VLAN, allowing for a manageable logical partitioning of IP addresses. The data center domain controller implements Microsoft Active Directory, which enables user and resource level object-oriented management at a level that's independent of the physical and logical network layer partitioning. The data center LAN is then protected beyond security appliances: a firewall and intrusion protection servers, as indicated in Section 1.5. Interconnection to the outside world via the redundant edge router consists of: Two SDSL Internet connections. One 3G broadband wireless backup/roaming Internet connection. One ATM link to the university's core network, which is located in the main campus few Kilometers away. Security Appliances Security appliances may be implemented in hardware or in software running on dedicated servers. They include (refer to Figure 3): Firewalls; to control inbound and outbound network access at port, application, and/or user level. Intrusion protection systems (IPS); which monitors incoming traffic to detect and protect against illegitimate network access attempts [1]. In addition, an antivirus application run on a dedicated server, performing the task of daily updating known virus and other malware signatures on clients installed at PCs, reporting infections, and logging detailed statistics about updates, infections, repairs, and all other related activities. IP Addressing Scheme The College of Engineering owns two Class-C IP address spaces, each providing for 256 unique IP addresses. These are: 210.134.8.x 210.134.12.x (x = [0, 255]) Dynamic addressing (supported by the DHCP server in the data center) is used for the majority of seats in public work areas, as well as all staff and faculty offices. Static addressing is also used for the data center servers and other appliances and labs and only 10% of the PC-equipped seats in public work areas. Static addresses are used where the application or functionality requires that and also in dedicated offices where one staff or faculty owns the static IP address, since the job nature requires the immediate availability of an IP address. Dynamic addresses are used otherwise where possible to make better use of the available IP address work space, taking advantage of the very fact that not all users will login simultaneously. Work area seats with dynamic addressing can still access internal network resources through the use of private IP addresses. Private IP addresses are not visible to the outside world such as the Internet or other interconnected university networks. They require the use of network address translation (NAT) when trying to access beyond the internal network. When a user logs in while there is a dynamic address shortage, they are notified upon login in that they cannot access the Internet at the time. However, they could still use local and internal resources. A user logged in with a private address is presented with a dialog window prompting the user to make reservation for a public address. DHCP server will allocate an address as soon as one is free and ask the user to re-login to obtain the public IP and be able to access external resources. The use of an HTTP proxy further alleviates the demand for public Internet addresses since it allows sharing a single Internet connection among multiple web browser clients. The detailed IP address allocation is provided in Table 3 below. Static range Dynamic range Electrical Engineering 210.134.8.0 - 40 210.134.8.41 - 120 Mechanical Engineering 210.134.8.121 - 190 210.134.8.191 - 255 Civil Engineering 210.134.12.0 - 45 210.134.12.46 - 96 Computing & Information 210.134.12.97 - 136 210.134.12.137 - 180 Engineering Library None 210.134.12.181 - 230 Data Center 210.134.12.231 - 255 None Table : IP address space allocation Internet Connectivity Internet connectivity to the internal network can be achieved using one or more of several current technologies: SDSL (Symmetric Digital Subscriber Line) over a dedicated leased line from the telecommunications service operator. ADSL (Asymmetric DSL) over a public (PSTN) telephone line. 3G broadband wireless provided by a mobile telephone service operator. The College of Engineering network is directly connected to the Internet via two diverted 16 Mbps SDSL connections over leased lines, operating in a load sharing mode, and backed up by a wireless 3G broadband HSUPA (High-Speed Uplink Packet Access) connection with a 16 Mbps download and 4 Mbps upload bit rates [2]. The last is also used for direct roaming laptop and smart mobile phone Internet access. The internal network is also linked to the university's core network via two diverted 16 Mbps ATM connections, which provide access to university central IT resources and also act as a third indirect route to the Internet in case of SDSL outage. Reference can be made to Figure 3 for a schematic representation. Network infrastructure In this section, Figure 2 provides a schematic representation of a typical department network layout, according to the fore mentioned specifications and descriptions. Figure 3 illustrated the overall campus network layout and how it connects to the outside world; which consists of both the public Internet and the private university wide intranet, where the later provides access to central university IT resources as well as cross access among university colleges and campuses. Figure : Local area network setup within a typical Engineering college department Figure : Campus wide network infrastructure layout Security Issues This section provides a discussion of the principles of some important security issues. Public vs. Private Cryptography Cryptography is the science and art of converting readable data into 'coded' cipher text to prevent unauthorized users from legibly reading it. The encryption algorithm is the computing mathematical procedure used to produce the cipher text (encrypt it) and to recover the original text (decrypt it). Encryption can be used to protect data both in storage and in transmission. There are two broad categories of encryption methods [3]: Public Key encryption: Also called asymmetric encryption, is a method whereby the sender and the recipient use a pair of different mathematically related keys that they both know; one for encrypting and the other for decrypting the data. Private Key encryption: Also called symmetric encryption, is a method whereby both the sender and the recipient use a shared 'secret' key for both encryption and decryption. This method, though more secure, is more cumbersome since each user needs to maintain multiple private keys; for communicating with each other user. Example Symmetric Cipher Data Encryption Standard (DES) is a popular "block" cipher that was developed in 1975 and was made a standard in 1981. It employs a 56-bit shared private key. Being described as a block cipher means that it encrypts a whole block of data a time, rather than encrypting individual bytes of a data stream. DES applies a 56-bit symmetric key (in addition to 8 parity bits) to each 64-bit block of data. Data chunks larger than this are broken into 64-bit blocks, and those smaller are padded with extra bits. DES applies a shift permutation of the block bits and then scrambles the whole block following a complex mathematical algorithm, which finally undergoes another permutation phase. In actual operation, the message sender encrypts the secret "shared" key with the recipient's public key, which was obtained from the sender's certificate. Only the recipient can decrypt the message since they have the secret key. In 1977, Rivest-Shamir-Adleman, who later developed the RSA encryption, offered a $10,000 reward for breaking a single DES message. A cooperative effort on the Internet with more than 14,000 users trying out various combinations managed to decrypt the message and discover the key after running one quarter of the 72 quadrillion possible combinations [4]. It can be seen that while this effort is hard to repeat, an encryption should be "virtually" impossible to break without knowledge of a private key. In addition to the relatively short key length of DES, symmetric key encryption is complex to implement since every pair of message exchangers need to share a private key, or otherwise it would have to be shared by a "community of users." Example Asymmetric Cipher RSA is the most well understood and implementable asymmetric cipher that has a key length of 512 to 2048 bits. The algorithm generates a private-public key pair by first multiplying two large prime numbers, followed by a series of additional mathematical operations. The prime numbers used to generate the key pair are discarded once it has been produced. The private key belongs to one owner and never has to leave his/her "custody." The public key is shared among any number of users. When encrypting a message, the client uses the sender's private key together with the recipient public key, where the later is either kept by the sender or more typically securely stored in a public key infrastructure (PKI). To decrypt the message, the recipient uses his/her private key together with the sender's public key. The power of this algorithm and in asymmetric encryption in general, is in the mathematical operations that keep an unnoticeable link between crossed pairs of private-public keys Even for those who are experts with the encryption operations detail, it is impossible to break the cipher without having the recipient's private key. Brute Force Attack Advanced Encryption Standard (AES) is a modern algorithm used by U.S. government agencies to protect sensitive, but not highly confidential, information. It employs a symmetric algorithm using 128, 192, or 256 bit keys. AES has been used by Microsoft Windows XP and Server 2003 for file encryption. A brute-force attack attempts to break the private key(s) by trying every possible value [4]. Assuming the shortest key length of 128 bits, the number of keys available is 2128 = 3.4 x 1038. Assuming a cracking rate of 106 combination per 1 micro second, the time required by an average desktop PC, the attacker needs 5.41018 years to walk through all combinations. Of course, a supercomputer may be able to perform the same job in much fewer years. Yet it is quite clear that it is not feasible to use this method of attack to break keys and the main risk lies within the human factor itself in protecting the actual key. Digital Signature A digital signature is a method of identity authentication of the creator or the sender of information. It relies on the same public key cryptography technology used for data encryption. Following are the steps needed to create a digital signature [3]: The message is first mathematically hashed to produce a message digest. The hash is then encrypted using the sender's private key to form the digital signature, which is either embedded within, or appended to, the message. The message recipient decrypts the hashed signature using the sender's public key. The recipient then hashes the original message and compares the result with the hash that resulted from decrypting the sender's hashed signature. If they both match, then the sender's identity had been verified. Digital signatures have the same legal power as handwritten signatures. They are not necessarily ties with message encryption. Their use should be encouraged and promoted to improve the eligibility and credibility of electronic transactions and correspondence. Message Authentication Code (MAC) A MAC encrypts a message digest with a session key to ensure that the content has not been modified in transit. MAC is accomplished through the following procedure at both the sender and recipient ends [3]: A hashing algorithm is first applied to generate a message hash. The sender then encrypts the hash using a session key, which is a secret key that is shared among the sender and the recipient. The resulting MAC is then attached to the message that is being sent. Once received, the recipient decrypts the MAC using the shared session key to recover the hash. The recipient then hashes the original message and compares the result to the decrypted has. If the two hashes match, then the message integrity has been verified, i.e. the messaged could not have been tampered with along the way. Comparison of Digital Signature and MAC Table 4 below provides a comparison between digital signature and MAC [4]. Digital signature Message Authentication Code (MAC) Uses asymmetric encryption (key pair) Uses a shared session key Encrypted hash can be embedded or attached to the message Encrypted hash is attached to the message Provides non-repudiation, i.e. proves that the message/document was signed by none but the sender's private key holder Does not provide non-repudiation: anyone who can verify the MAC is also capable of generating MACs for other messages TCP Congestion Control TCP is the transport layer protocol that acts on behalf of application level protocols in encapsulating datagram IP packets and ensuring their "eventual" delivery via reliable connection. Congestion control refers to network congestion avoidance by controlling traffic rates within the network intermediary nodes. It is different in principle from flow control that refers to controlling the inbound traffic rates at the sender side so that it will not overwhelm the recipient nodes [6]. Congestion control algorithms can be classified according to any of the following parameters [7]: Quantitative feedback received from the network, such as packet loss or delay. Increment deployability onto the existing network, i.e. the network node or element that needs modification: only sender, both sender and receiver, only routers, etc. need modification. Performance aspect it attempts to improve: packet loss rate, end-to-end delay, jitter, fairness, or advantage to certain rates/flows. Algorithm Principle of Operation The TCP congestion control algorithm has each side of the connection keep track of two variables: the congestion window and the threshold. The congestion window imposes a constraint on the amount of traffic a host can send into a connection. TCP window size denotes the number of permissible unacknowledged packets that a host can send. The amount of unacknowledged data a host can send within an open TCP connection should not exceed the minimum of the window and the threshold [7, 8]. 1 When the congestion window is below the threshold, the congestion window is allowed to grow exponentially. 2 When the congestion window is above the threshold, it is allowed to grow only linearly. 3 Whenever there is time-out, the threshold is set to one half of the current congestion window and the congestion window is then set to 1. Figure : Conceptual illustration of traffic congestion in TCP/IP networks and the basic principle of congestion control algorithms (Source: University of Edinburgh, School of Informatics, Computer Communications course notes) Implementations Comparison To avoid congestion collapse, TCP uses a multi-faceted congestion control strategy. For each connection, TCP maintains a congestion window, limiting the total number of unacknowledged packets that may be in transit end-to-end. TCP uses a mechanism called slow start [7,8] to increase the congestion window after a connection is initialised and after a timeout. It starts with a window of two times the maximum segment size (MSS). Although the initial rate is low, the rate of increase is very rapid: for every packet acknowledged, the congestion window increases by 1 MSS so that for every round trip time (RTT), the congestion window has doubled. When the congestion window exceeds a threshold the algorithm enters a new state, called congestion avoidance. The threshold is updated at the end of each slow start, and will often affect subsequent slow starts triggered by timeouts. Congestion avoidance: As long as non-duplicate ACKs are received, the congestion window is additively increased by one MSS every round trip time. When a packet is lost, duplicate ACKs will be received. The behaviour of Tahoe and Reno differ in how they detect and react to packet loss: Tahoe: Loss is detected when a timeout expires before an ACK is received. Tahoe will then reduce congestion window to 1 MSS, and reset to slow-start state. Reno: If three duplicate ACKs are received (i.e., three ACKs acknowledging the same packet, which are not piggybacked on data, and do not change the receiver's advertised window), Reno will halve the congestion window, perform a "fast retransmit", and enter a phase called Fast Recovery. If an ACK times out, slow start is used as it is with Tahoe. Fast Recovery (Reno Only): In this state, TCP retransmits the missing packet that was signaled by 3 duplicate ACKs, and waits for an acknowledgment of the entire transmit window before returning to congestion avoidance. If there is no acknowledgment, TCP Reno experiences a timeout and enters the slow-start state. Both algorithms reduce congestion window to 1 MSS on a timeout event. Vegas [9]: TCP Vegas detects congestion at an incipient stage based on increasing Round Trip Time (RTT) values of the packets in the connection unlike algorithms that detect congestion only after it has actually happened via packet drops. It depends on accurate calculation of the Base RTT value. If RTT is too small, then there will be less than the bandwidth available throughput of the connection, while if the value is too large then it will overrun the connection. An interesting issue that is being investigated is the fairness provided by the linear increase/decrease mechanism for congestion control in Vegas, especially when it is inter-operated with other versions like Reno. In this case, performance of Vegas degrades because Vegas reduces its sending rate before Reno as it detects congestion early and hence gives greater bandwidth to co-existing TCP Reno flows. Database driven web content & performance of HTTP Proxies A static web page contains content that displays the same for all users, regardless of user input. Dynamic web pages are written in a high level language that displays markup and other objects depending on the interactions with the user. Common examples are a membership based site or a commercial site, where the user fills out and submits forms and get access to content or receive responses depending on the submitted information [10]. Using a database in conjunction with your Web pages allows structuring the backend data in a layer that is independent of the site presentation. The example of membership sites and forums illustrates that a database is essential to maintain current user associated information [11]. The most common use of a web proxy is to serve as a web cache. A caching proxy server accelerates service requests by retrieving content saved from a previous request made by the same client or even other clients. Caching proxies keep local copies of frequently requested resources, allowing large organizations to significantly reduce their upstream bandwidth usage and cost, while significantly increasing performance [11]. Since application servers, databases, web servers, and caches are independent components, there is no efficient mechanism to make changes in the database content reflected to the cached web pages. As a result, most application servers have to mark dynamically generated web pages as non-cacheable. Non-cacheable pages would typically require more time to be downloaded. On one hand they have to always be brought from source, and on the other they are not only brought but also generated after accessing the related database. This clearly illustrated that the average access time of database-driven dynamically generated web content exceeds dynamic content that is generated "on the fly" without accessing a database, and that both times exceed the access time of a simple cached static page. Conclusion This document demonstrates the understanding of some major aspects of computer networking, over three distinct sections. Section 1 considered the internal network of the College of Engineering and presented detailed high level description of user, server, network, and security designs of the network and how it connects to the Internet and to the university core intranet. Section 2 examined the important topic of data encryption. Symmetric and asymmetric ciphers have been described and contrasted. Examples of each have been provided. Also, the use of encryption for message authentication in the form of digital signature and/or message authentication code was discussed and the two schemes were compared. Section 3 considered the topic of congestion control and avoidance for TCP/IP networks, which make the overall transport infrastructure of almost all today's public and private data networks. Congestion control algorithms were discussed at a topical level and a comparative description of three algorithms (Tahoe, Reno and Vegas) was provided. Section 3 concluded with describing the role of an HTTP proxy and the performance penalty it encounters due to the common use of database driven dynamic web content. Appendix - Glossary of Used Acronyms ACK Acknowledgement (frame or packet type) ADSL Asymmetric Digital Subscriber Line AES Advanced Encryption Standard ATM Asynchronous transfer Mode CAD Computer Aided Design DES Data Encryption Standard DHCP Dynamic Host Control Protocol HSUPA High-Speed Uplink Packet Access HTTP HyperText Transfer Protocol IPBX IP (Internetworking Protocol) Private Branching Exchange IPS Intrusion Protection System MAC Media Access Control MAC Message Authentication Code MSS Maximum Segment Size NAT Network Address Translation NIC Network Interface card NMC Network Management Centre PKI Public Key Infrastructure PSTN Public Switched Telephone Network RSA Rivest-Shamir-Adleman (an encryption algorithm) RTT Round trip Delay SDSL Symmetric Digital Subscriber Line TCP Transport Control Protocol VLAN Virtual Local Area Network Wi-Fi Wireless Fidelity Bibliography 1. Ogeltree, T.W., Practical Firewalls, QUE, 2000. 2. http://en.wikipedia.org/wiki/HSUPA 3. Tulloch, M. (2003), Microsoft Encyclopedia of Security, Microsoft Press. 4. Regan, P. (2005), Acing the Security+ Certification Exam, Pearson Prentice Hall. 5. http://en.wikipedia.org/wiki/Message_authentication_code 6. http://en.wikipedia.org/wiki/Congestion_control 7. http://en.wikipedia.org/wiki/TCP_congestion_avoidance_algorithm 8. Jacobson, V., Karels, M.J. (1988), Congestion Avoidance and Control, Proceedings of the ACM SIGCOMM '88 Symposium, vol.18 (4): pp.314-329. 9. http://en.wikipedia.org/wiki/TCP_Vegas 10. Krishnamurthy, B., Rexford, J. (2001), Web Protocols and Practice, Addison Wesley. 11. Candan, K.S., Li, W-S., Luo, Q., Wang-Pin, Agrawal, D., Enabling dynamic content caching for database-driven web sites, Proceedings of the 2001 ACM SIGMOD international conference on Management of data, Pages: 532 - 543 (http://portal.acm.org/citation.cfmid=375663.375736) Read More