Let us suppose that a client application on host A on network P wishes to connect to a server application on host B on network Q. The client and server applications run as processes on the respective hosts. The client application creates data that is sent down the protocol stack to the transport layer. The transport layer adds information to this data in a structured manner creating a segment that is passed down to the network layer. The transmission control protocol (TCP) and the user datagram protocol (UDP) are two common transport layer protocols.
The transport layer segment forms the payload of a network layer packet or datagram usually carried by the Internet protocol (IP). The IP datagram is further carried by a link or medium access control (MAC) layer protocol in a frame on each link between host A and host B (examples are Ethernet and WiFi). Each link may have its own physical layer-dependent transmission mechanisms. At the transport layer, a port number will identify the process in host A; let us denote this port number as P A . Host A will have an IP address that belongs to network P; let us denote this as IP A . The tuple _ P A , IP A _ , which is sometimes called a socket , is a globally unique identifi er of the client process that intends to communicate with the server process. Similarly, the server process will be associated with a port number P B and an IP address IP B . A connection between the client and server can thus be uniquely identifi ed through the tuple _ P A , IP A , P B , IP B _ . The transport layer segment consists of a header containing the source port P A and the destination port P B . The IP datagram has a header that contains the source IP address IP A and the destination IP address IP B . Network interface cards only recognize the MAC address. When the network interface card in host A creates a MAC frame on the physical medium of network P, it typically uses a 48-bit source MAC address and a 48-bit destination MAC address. Obviously, host B is on a different network, possibly using a different link and physical layer. Thus, the destination MAC address does not belong to host B, but instead to a gateway or router that connects network P to other networks or the Internet. The IP address of the gateway is either manually installed in host A or host A fi nds this information using a dynamic host confi guration protocol (DHCP). DHCP is also used to dynamically assign IP addresses to hosts in a network. However, knowledge of simply the IP address of the gateway does not suffi ce since the MAC address is necessary for the frame to be received by the gateway. A mapping of the IP address to the MAC address can be obtained using the address resolution protocol (ARP). Similarly, when a frame arrives at the gateway from the Internet to the host on the network Q, the gateway will have to use the ARP to determine the MAC address of the destination host. The gateway is responsible for routing the IP datagram in the received MAC frame to another router in the Internet, which forms a node on one of the available paths to the destination network Q. Such paths are determined using routing information through routing protocols like the routing information protocol (RIP), open shortest path fi rst (OSPF), and border gateway protocol (BGP). How does the application process on host A know the IP address of host B? Usually, the IP address is not known, instead a domain name such as “ www.cnn .com ” that is human friendly is used in the application. It is necessary for host A to use the domain name service (DNS) to determine the IP address of host B. This has to happen prior to the actual data being sent in an IP packet to host B. Each network has a local name server that is known to every host in that network (possibly through DHCP). Host A contacts the local name server when the application process in host A desires to send a packet to host B with information about host B (say “ www.cnn.com ” ). If the local name server has cached information about the IP address of host B, it provides that information to host A immediately. If not, it contacts a root name server (there are only 13 of these worldwide). The root name servers have information about authoritative name servers that in turn have information related to hosts on their networks. In the above example, the root name server may provide the local name server of network P, the IP address of the authoritative name server for network Q. The local name server of network P then contacts the authoritative name server of network Q to obtain the IP address of host B. Then the IP address is forwarded to host A. Now suppose that host A was successful in fi nding the IP address of host B using DNS. The application process in host A with port number P A sends data to a process in host B with port number P B . How did the process in host A know the port number P B ? Standard applications have standard port numbers. For example, a web server usually employs the port number 80, a telnet server uses 23, a web server running the secure sockets layer (SSL) uses 443, the simple mail transport protocol (SMTP) uses 25, and so on. Port numbers may also be changed after initial contact as in the case of protocols like the fi le transfer protocol (FTP) or applications like Skype. Although port numbers for standard services are well known, this does not automatically imply that such services are not available at other port numbers. For instance, it is quite possible to run a web server at a port number other than 80. Services on servers “ listen ” for initial contact from clients at the standard port numbers. These are what we call “ open ” ports. When a packet from host A arrives at host B, it is sent up the protocol stack to the transport layer where the server that is listening at port number P B receives the application data in the transport layer segment. The server processes the data appropriately and responds to the client at port number P A , which is known because of the initial received packet. Figure a very simplified view of some of the many protocols and applications that are common in networked communications today. It is to be noted that this is just a very small fraction of the protocols and applications in use. Each of these protocols could perhaps create security problems because they are capable of being abused by malicious entities in ways in which they were not anticipated to be used. Security problems occur for a variety of reasons, but one common reason is that servers listening at known ports have bugs in their implementation (e.g., buffer overflows). For example, it is possible for a malicious entity (we will refer to a malicious entity—a human, a criminal organization, or software—as Oscar in this chapter) to craft packets that can be sent to buggy services. When a service is compromised, it can enable Oscar to take control over the host. This means Oscar can perhaps install malicious software on the host, use the host to launch other malicious packets, steal files that are stored on the host or on other hosts on the network that trust the compromised host, and so on as described in the following examples.