Network Primer

This course requires some background knowledge about networking and operating systems. In this material we will cover some networking basics that will help you understand how some security threats work and why it is difficult to find effective solutions against them.

In all network communications one machine - client - initiates communication with another machine - server.

Addressing

Each machine on the Internet has an IP address consisting of four octets - four numbers ranging between 0 and 255. These numbers are separated by dots, e.g., 1.2.3.4 or 128.125.253.146. Some IP addresses are reserved for special use. You can think of the IP address as similar to the address of a building, that you use when you send postal mail. You write the address on the envelope and the post office uses it to route mail to its destination.

Naming

Each machine on the Internet also has a human-friendly name like www.usc.edu or www.google.com. This name also has multiple parts separated by dots. Names are easy for humans to remember but when messages travel on the Internet there must be a destination address - the IP address - attached to them that tells the routers where to send them. This means that someone needs to translate the names into IP addresses. The service that does this is called Domain Name System or DNS.

DNS

You can envision DNS like 411 service for the Internet, translating host names into IP addresses and vice versa. DNS is a distributed service, which means parts of the directory reside in databases stored on different servers. Each server can be "in charge" of some names - we say it is authoritative server for those - or it can be a caching server, storing information it sees for a limited time. Each authoritative server is in charge of a domain - a suffix created by using dots in the name as separators. For example, for domain www.usc.edu one server (commercial) would be in charge of all addresses ending in .edu and another server (located at USC) would be in charge of all addresses ending in .usc.edu.

How does your computer then find out which server to ask for translation? Each computer is preconfigured with several addresses of "local DNS servers" - machines internal to the network the computer is currently connected to, that will proxy the translations. Each computer also has a DNS resolver, client application that will initiate translation requests. When you type a domain name, e.g., into your browser the DNS resolver contacts the local DNS server and asks about that name's translation. For example, at USC the server would contact 128.125.253.136 or 128.125.253.156. If another user recently asked for the same domain name the reply may be in the server's cache and it will provide it to the resolver. Otherwise the local DNS server will do one of two things: (1) resolve the name for the client, provide the answer and cache it (recursive service) or (2) point the client to the server that can help it (iterative service).

In both cases the client (or the local DNS server) starts the query at the authoritative server in charge of the longest suffix of the domain name that it knows about. For example, when resolving www.google.com a local DNS server at USC, acting recursively, could start with the server in charge of google.com if that mapping were in its cache. Or with the server in charge of .com if that mapping were in its cache. If no suffix mappings were in the cache the server would start with one of 13 root DNS servers. These servers fully replicate each other's content and are geographically well distributed. The root server would tell the local DNS server what is the IP address of the authoritative server for .com, and this server would tell it what is the IP address of the authoritative server for google.com. This server (google.com) would know the IP addess of www.google.com and would return it to the local DNS server, who would return it to the resolver on your computer. For more details about DNS see DNS On Wikipedia.

Headers

Each message that goes onto network has prepended several headers. The application that creates the message prepends the application header. This header usually tells the server at the other side some information about the message. For example, the HTTP header has "message type" inside telling the server if this is a GET request (so the server should fetch the Web page specified in the message) or the POST request (so the server should pass the information from the message to some Web page for processing). The operating system prepends the transport header (often, TCP or UDP) and the IP header. The transport header has some information for the transport protocol (more about this shortly) and the IP header has information that helps route the message, such as the IP addresses of the source and the destination. The IP address of the destination is there so that the network could route the message. The IP address of the source tells the server who initiated the communication and the server sends the response back to that host.

Both the TCP and the UDP headers hold source and destination port numbers. If you think of an IP address as the address of a building, the port number would be address of the apartment in that building. There are 65535 ports on each computer. Port numbers help the operating system deliver the network messages to the proper application. For example, imagine that you are running a Web browser on your machine, and a chat client. Both these applications need to communicate over the network, and both are at the same IP adress. When a message comes from the network the OS needs to know which application to give it to. The port number in the message tells the OS where to deliver it. The application in turn listens to events at that port number and consumes messages as they arrive from the network. Servers usually reside at "well-known" port numbers so that client applications always know which number to use to reach them. For example, a Web server always listens on port 80. The client application chooses a port number, attaches itself to it and communicates this number to the server via the "source port" field in the transport header.

UDP stands for User Datagram Protocol. It simply sends messages from source to destination and provides no assurance of their delivery. Applications that care about reliable delivery need to provide this service themselves. For more information about UDP see UDP on Wikipedia

TCP stands for Transmission Control Protocol. It strives to provide reliable delivery from the source to the destination. TCP segments messages from the application into chunks and prepends the TCP header to them. This header holds the sequence and the acknowledgment number for each segment and some other control information. You can think of the sequence number as the number showing the order of this segment in the communication (first, second, third, etc.) except that it starts from a random number and it counts bytes instead of segments. When TCP sends a segment (a packet) to the destination it waits for acknowledgment to come back saying "I got this packet". If the acknowledgment does not come back for a while TCP will repeat this packet. Acknowledgments are most-times cumulative (there are several TCP variations), e.g., if the destination sends "ack 30" it means it got all the segments numbered up to and including 30. Thus if an acknowledgment is lost but another arrives with the higher number the TCP sender will infer from it that all packets up to that number arrived successfully.

The link header is prepended last. It contains information about the sender's and the destination's MAC address - the physical address of the network cards. This information is valid only for one hop and the next router on the path overwrites it.

Routing

How does a packet on the network arrive from its source to the destination? How does the network know which route to take? First, imagine that the source and the destination were one hop away, as shown in the picture below.

The source A needs to figure out where to send the packet for B. It looks into its routing table that only says "all traffic must go on interface with MAC address MACA" because this machine only has one interface. It then sends a query on that interface trying to learn the MAC address of the destination. The query looks like this "Who has IPB? Tell MACA" and B replies "MACB has IPB". The protocol that specifies this behavior is called ARP protocol - Address Resolution Protocol. The MAC addresses in the ARP query and the ARP reply help network interfaces at the machines understand that the packet is for them. While in my picture there are only A and B on this link in reality there may be many machines attached to a common channel (e.g., broadcast Ethernet or WiFi). They can all hear all the packets but will only consume those that are for their MAC address. Mappings between IPs and MACs get stored in ARP cache for a limited time.

Now imagine that A and B are three hops away like shown in the picture below. We will skip the ARP request/reply to find out which MAC belongs to which IP, assuming these mappings already exist in ARP cache.

Each node in the picture will first build a routing table showing the next hop to some destination. This table is built by nodes exchanging information with each other about destinations they already know about, such as their own IPs and the IPs of the nodes they are directly connected to. The packet starts from A carring the IPB as the destination IP address in the IP header, IPA as the source IP address in the IP header and MACA and MACC as source and destination MAC addresses in the link header. C looks up in its routing table information about next hop to IPB and overwrites the link header putting MACC and MACD as source and destination addresses. Similarly, D overwrites it with MACD and MACB. Finally, packet arrives at B, which consumes it.