Network Security

NETWORK SECURITY

In the last decade, the number of computers in use has exploded. For quite some time now, computers have been a crucial element in how we entertain and educate ourselves, and most importantly, how we do business. It seems obvious in retrospect that a natural result of the explosive growth in computer use would be an even more explosive (although delayed) growth in the desire and need for computers to talk with each other. For quite some time, businesses were primarily interested in sharing data within an office or campus environment, this led to the development of various protocols suited specifically to this task.

Within the last five years, businesses have begun to need to share data across wide areas. This has prompted efforts to convert principally LAN-based protocols into WAN-friendly protocols. The result has spawned an entire industry of consultants who know how to manipulate routers; gateways and networks to force principally broadcast protocols across point-to-point links. Frequently the protocol of choice has been TCP/IP which is also the primary protocol run on the Internet. The emerging ubiquitous ness of TCP/IP allows companies to interconnect with each other via private networks as well as through public networks.

In today's world businesses, governments, and individuals, all are communicating with each other across the world. While reality is rapidly approaching this utopian picture, several relatively minor issues have changed status from low priority to extreme importance. Security is probably the most well known of these problems. When businesses send private information across the net, they place a high value on it getting to its destination intact and without being intercepted by someone other than the intended recipient. Individuals sending private communications obviously desire secure communications. Finally, connecting a system to a network can open the system itself up to attacks. If a system is compromised, the risk of data loss is high.

It can be useful to break network security into two general classes:

* Methods used to secure data as it transits a network

* Methods which regulate what packets may transit the network

While both significantly affect the traffic going to and from a site, their objectives are quite different.

Transit Security

Currently, there are no systems in wide use that will keep data secure as it transits a public network. Several methods are available to encrypt traffic between a few coordinated sites. Unfortunately, none of the current solutions scale particularly well. Two general approaches dominate this area:

1. Virtual Private Networks: When a virtual private network is implemented, the lowest levels of the TCP/IP protocol are implemented using an existing TCP/IP connection. There are a number of ways to accomplish this which tradeoff between abstraction and efficiency. The advantage this gives you in terms of secure data transfer is only a single step further away. Because a VPN gives you complete control over the physical layer, it is entirely within the network designer's power to encrypt the connection at the physical (virtual) layer. By doing this, all traffic of any sort over the VPN will be encrypted, whether it be at the application layer (such as Mail or News) or at the lowest layers of the stack (IP, ICMP). The primary advantages of VPNs are: they allow private address space (you can have more machines on a network), and they allow the packet encryption/translation overhead to be done on dedicated systems, decreasing the load placed on production machines.

2. Packet Level Encryption: Another approach is to encrypt traffic at a higher layer in the TCP/IP stack. Several methods exist for the secure authentication and encryption of telnet and rlogin sessions (Kerberos, S/Key and DESlogin), which are examples of encryption at the highest level of the stack (the application layer). The advantages to encrypting traffic at the higher layer are that the processor overhead of dealing with a VPN is eliminated, inter-operability with current applications is not affected, and it is much easier to compile a client program that supports application layer encryption than to build a VPN. It is possible to encrypt traffic at essentially any of the layers in the IP stack. Particularly promising is encryption that is done at the TCP level, which provides fairly transparent encryption to most network applications.

Both of these methods can have performance impacts on the hosts that implement the protocols, and on the networks, which connect those hosts. Both methods have impacts on other areas (security related and otherwise- such as address allocation, fault tolerance and load balancing) that need to be considered before any choice is made as to which is best for a particular case.

Traffic Regulation

The most common form of network security on the Internet today is to closely regulate which types of packets can move between networks. If a packet, which may do something malicious to a remote host never, gets there, the remote host will be unaffected. Traffic regulation provides this screen between hosts and remote sites. This typically happens at three basic areas of the network: routers, firewalls, and hosts. Each provides similar service at different points in the network. In fact the line between them is somewhat ill defined and arbitrary.

Almost all packets (besides those at the lowest levels which deal with network reach ability) are sent to destination sockets of either UDP or TCP. Typically, packets from remote hosts will attempt to reach one of what are known as the well-known ports. These ports are monitored by applications, which provide services such as Mail Transfer and Delivery, Usenet News, the time, Domain Name Service, and various login protocols. It is trivial for modern routers or firewalls only to allow these types of packets through to the specific machine that provides a given service. Attempts to send any other type of packet will not be forwarded. This protects the internal hosts, but still allows all packets to get out. Unfortunately this isn't the panacea that it might seem.

* The problem of returning packets: Let's pretend that you don't want to let remote users log into your systems unless they use a secure, encrypting application such as S/Key. However, you are willing to allow your users to attempt to connect to remote sites with telnet or ftp. At first glance, this looks simple: you merely restrict remote connections to one type of packet and allow any type of outgoing