Link Versus End To End Encryption Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Although this recourse requires a lot of encryption devices in a large network, its value is clear. One of its disadvantages is that the message must be decrypted each time it enters a packet switch because the switch must read the address (virtual circuit number) in the packet header in order to route the packet.

Thus, the message is vulnerable at each switch. If working with a public packet switching network, the user has no control over the security of the nodes.

Several implications of link encryption should be noted. For this strategy to be effective,

all the potential links in a path from source to destination must use link encryption. Each

pair of nodes that share a link should share a unique key, with a different key used on each link. Thus, many keys must be provided. However, each key must be distributed to only two nodes. With end-to-end encryption, the encryption process is carried out at the two end systems.

The source host or terminal encrypts the data. The data in encrypted form are then

transmitted unaltered across the network to the destination terminal or host. The estination shares a key with the source and so is able to decrypt the data. This plan seems to secure the transmission against attacks on the network links or switches. Thus, end-toend encryption relieves the end user of concerns about the degree of security of networks and links that support the communication. There is, however, still a weak spot.Consider the following situation. A host connects to an X.25 packet-switching network,sets up a virtual circuit to another host, and is prepared to transfer data to that other host by using end-to-end encryption. Data are transmitted over such a network in the form of packets that consist of a header and some user data. What part of each packet will the host encrypt? Suppose that the host encrypts the entire packet, including the header. This will not work because, remember, only the other host can perform the decryption. The packet switching node will receive an encrypted packet and be unable to read the header.

Therefore, it will not be able to route the packet. It follows that the host may encrypt only

the user data portion of the packet and must leave the header in the clear.

Thus, with end-to-end encryption, the user data are secure. However, the traffic pattern is not, because packet headers are transmitted in the clear. On the other hand, end-to-end encryption does provide a degree of authentication. If two end systems share an

encryption key, then a recipient is assured that any message that it receives comes from the alleged sender, because only that sender shares the relevant key. Such authentication is not inherent in a link encryption scheme.

To achieve greater security, both link and end-to-end encryption are needed, as is shown in above Figure . When both forms of encryption are employed, the host encrypts the user data portion of a packet using an end-to-end encryption key. The entire packet is then encrypted using a link encryption key. As the packet traverses the network, each switch decrypts the packet, using a link encryption key to read the header, and then encrypts the entire packet again for sending it out on the next link. Now the entire packet is secure except for the time that the packet is actually in the memory of a packet switch, at which time the packet header is in the clear.

Logical Placement of End-to-End Encryption Function

With link encryption, the encryption function is performed at a low level of the

Communications hierarchy. In terms of the Open Systems Interconnection (OSI) model,

link encryption occurs at either the physical or link layers. For end-to-end encryption, several choices are possible for the logical placement of the encryption function. At the lowest practical level, the encryption function could be performed at the network layer. Thus, for example, encryption could be associated with X.25, so that the user data portion of all X.25 packets is encrypted. With network-layer encryption, the number of identifiable and separately protected entities corresponds to the number of end systems in the network. Each end system can engage in an encrypted exchange with another end system if the two share a secret key.

All the user processes and applications within each end system would employ the same

encryption scheme with the same key to reach a particular target end system. With this

arrangement, it might be desirable to off-load the encryption function to some sort of

front-end processor (typically a communications board in the end system).

Deployment of encryption services on end-to-end protocols, such as a network-layer X.25 or TCP, provides end-to-end security for traffic within a fully integrated internetwork.

However, such a scheme cannot deliver the necessary service for traffic that crosses

internetwork boundaries, such as electronic mail, electronic data interchange (EDI), and

file transfers.The below Figure illustrates the issues involved. In this example, an electronic mail gateway is used to interconnect an internetwork that uses an OSl-based architecture with one that uses a TCP/IP-based architecture. In such a configuration, there is no end-to-end protocol below the application layer. The transport and network connections from each end system terminate at the mail gateway, which sets up new transport and network connections to link to the other end system. Furthermore, such a scenario is not limited to the case of a gateway between two different architectures. Even if both end systems use TCP/IP or OSI, there are plenty of instances in actual configurations in which mail gateways sit between otherwise isolated internetworks. Thus, for applications like electronic mail that have a store-and-forward capability, the only place to achieve end-to-end encryption is at the application layer.

A drawback of application-layer encryption is that the number of entities to consider

increases dramatically. A network that supports hundreds of hosts may support thousands of users and processes. Thus, many more secret keys need to be generated and distributed. An interesting way of viewing the alternatives is to note that as we move up the communications hierarchy, less information is encrypted but it is more secure. Below figure highlights this point, using the TCP/IP architecture as an example. In the figure, an application-level gateway refers to a store-and-forward device that operates at the application level. (Unfortunately, most TCP/IP documents use the term gateway to refer to what is more commonly referred to as a router. With application-level encryption , only the user data portion of a TCP segment is encrypted. The TCP, IP, network-level, and link-level headers and link-level trailer are in the clear. By contrast, if encryption is performed at the TCP level , then, on a single end-to-end connection, the user data and the TCP header are encrypted. The IP header remains in the clear because it is needed by routers to route the

IP datagram from source to destination. Note, however, that if a message passes through a gateway, the TCP connection is terminated and a new transport connection is opened for the next hop. Furthermore, the gateway is treated as a destination by the underlying IP.

Thus, the encrypted portions of the data unit are decrypted at the gateway. If the next hop is over a TCP/IP network, then the user data and TCP header are encrypted again before transmission. However, in the gateway itself the data unit is buffered entirely in the clear. Finally, for link-level encryption , the entire data unit except for the link header and trailer is encrypted on each link, but the entire data unit is in the clear at each router and gateway.