One idea that has helped the success of the early Internet is that its infra- structure permitted early end-2-end applications, such as Telnet and FTP.
Services with end-2-end architecture [1] by definition have a distributed structure because they push complexity to the end points of the network.
The idea is to keep the network simple and build any needed complexity into the end, or edges, of the network. Applications that are end-2-end are unknown to the network infrastructure because there are no application- specific functions in the network. This means that changes to the network or permission to add new end-2-end services is not necessary because nothing within the network knows about a new service. The end-2-end
Internet End-2-End Argument 37
argument is one of increased innovation, and the proof of its validity is the success of the Internet with regard to innovation.
One example illustrating what end-2-end services look like compares hop-by-hop to end-2-end encryption of data [2][3], as depicted in Figure 3.1. In the hop-by-hop case, the network node in between Bob and Alice must understand what Bob and Alice are doing. This transit node (Tom) must have knowledge about the encryption application that Bob and Alice are using. This node in the middle might be independent of both Bob and Alice, but Bob and Alice must keep it appraised of the application they are running. This makes the service not end-2-end. In this hop-by-hop case, Bob encrypts his message in a key common to him and the node the mes- sage must transit in its journey to Alice. Tom decodes the message in the key shared with Bob, and reencrypts the message in a key shared with Alice (which is likely different from the key the transit node shares with Bob). Finally, Tom sends the message to Alice in the key it shares with her.
This hop-by-hop method is not secure because Tom knows how to decode the message. The end-2-end case is less complex. Bob encrypts his message in a key shared only with Alice, and the transit node cannot look at the message. Tom must only receive the message from Bob and forward it to Alice. This end-2-end methodology is more secure because nobody in the middle of the network can view this message from Bob to Alice. In the end- 2-end case, only Bob and Alice need to know what they are doing. The node in the middle knows only that it must forward any data from Bob to Alice, and from Alice to Bob. This application independence of Alice and Bob to the network infrastructure is what makes the service end-2-end.
The advantages of end-2-end encryption include the following:
■■ Increased security because no transit nodes are able to decode the encrypted message. Trusting a third party should be problematic to Bob and Alice. Intuitively, it makes no sense for Bob and Alice to trust someone else.
■■ Less processing overhead because the transit node does not need to decode and then reencrypt the message. Both encryption and decryption require extensive computer resources.
■■ Ability to change and innovate because Bob and Alice can do what they wish without informing any transit nodes. This includes chang- ing encryption/decryption keys and invoking new security methods at their own discretion without informing the manager at the transit node. This enhances the ease with which Bob and Alice can experi- ment and innovate because they need only each other.
38 Chapter 3
Figure 3.1 End-2-end encryption service.
In the preceding case it is obvious that the end-2-end method is better in all aspects: It is more secure, efficient, and flexible. Don’t be fooled by this example; there are many cases of network-based services where the choice of whether end-2-end architecture makes sense is not so simple. In the past as well as at present, distributed management of network-based services, such as email and voice, makes sense in some cases, even though the cost of providing the end-2-end architecture exceeds that of a centralized man- agement structure.
The end-2-end argument states that services offered by the network infrastructure should be as simple as possible. If you try to anticipate the services applications will need, you may be wrong, and you will most likely inhibit new applications by constraining them with services that do not match their needs. Networks that provide only simple, basic services allow applications more flexibility in what they can do. The IP protocol in the Internet is a good example of this philosophy; it is simple, offering just the most basic type of network service — the unreliable datagram service.
Bob's message to Alice encrypted with Alice's/Transit Node's key
At Transit Node Bob's message is
decoded with Bob/Transit key, then encrypted with Alice/Transit Key
Bob's message to Alice encrypted with Bob's/Transit Node's key
hop-by-Hop Encryption Bob
Alice
Tom
Transit Node
Bob's message to Alice encrypted with Bob's/Alice's key
At Transit Node Bob's message is forwarded to Alice
Bob's message to Alice encrypted with Bob's/Alice's key
End-to-End Encryption Bob
Tom
Transit Node Alice
Internet End-2-End Argument 39
This simple core protocol has allowed immense innovation at the transport and application layers. Different application modules can utilize different transport protocols that match their needs, but all of them are built over IP, which has become the glue holding the Internet together. The success of the Internet is partially due to the simplicity of IP. Again, this validates the end-2-end argument.
By pushing applications to the user level with end-2-end applications, more experimentation is likely. There are several reasons for this. First, application-layer development is faster and less expensive than kernel work because kernel code tends to be complex and debugging is often difficult. Next, the pool of talent with the skills to do application-layer cod- ing is greater. Finally, those programmers allowed to develop new services are much broader at the application level because they include users, and as Hippel [4] shows, users sometimes are best suited to solve their own problems.
Because end-2-end applications do not require network infrastructure change or permission to experiment, users can and do innovate new ser- vices. Consider the creation of the Web. Tim Berners-Lee [5] was not a net- work researcher searching for innovative ways to utilize the Internet, he was an administrator trying to better serve his users. He developed the World Wide Web to allow the scientists in his organization to share infor- mation across diverse computers and networks. It just so happened that his solution, the Web, met many other user needs far better than anything else at the time. This illustrates one powerful attribute of the end-2-end argument — you never know who will think of the next great idea, and with end-2-end services, it can be anybody.