This chapter is from the book
This chapter is from the book
This chapter is from the book
Packets: IP Network Messages
The term packet refers to an Internet Protocol (IP) network message. The IP standard defines the structure of a message sent between two computers over the network. It's the name given to a single, discrete message or piece of information that is sent across a network. Structurally, a packet contains an information header and a message body containing the data being transferred. The body of the IP packet—its data—is all or a piece (a fragment) of a higher-level protocol message.
The IP firewall mechanisms included in Linux support three IP message types: ICMP, UDP, and TCP. An ICMP (Internet Control Message Protocol) packet is a network-level, IP control and status message. At the network level, ICMP messages contain information about the communication between the two endpoint computers as well as individual routers along the way. A UDP (User Datagram Protocol) IP packet carries UDP transport-level data between two network-based programs, without any guarantees regarding successful delivery or packet delivery ordering. Sending a UDP packet is akin to sending a postcard to another program. A TCP (Transmission Control Protocol) IP packet carries TCP transport-level data between two network-based programs, as well, but the packet header contains additional state information for maintaining an ongoing, reliable connection. Sending a TCP packet is similar to carrying on a phone conversation with another program. Most historically common Internet network services use the TCP communication protocol rather than the UDP communication protocol. In other words, most Internet services are based on the idea of an ongoing reliable connection with two-way communication between a client program and a server program.
As shown in Figure 1.5, all IP packet headers contain the source and destination IP addresses and the type of IP protocol message (ICMP, UDP, or TCP) this packet contains. Beyond this, a packet header contains slightly different fields depending on the protocol type. ICMP packets contain a type field identifying the control or status message type, along with a second code field for defining the message more specifically. UDP and TCP packets contain source and destination service port numbers. TCP packets contain additional information about the state of the connection and unique identifiers for each packet. (The header contains other fields, as well. Depending on the firewall technology, the remaining fields may or may not be used, or even visible, at the packet-filtering level.
Figure 1.5. IP Header.
The complete list of fields in the IP header are:
Version—The first 4 bits of the header contain the IP version. Version 4 is in use today. Version 6 will replace it.
Header Length—The next 4 bits contain the number of 32-bit words making up the header. IP headers are usually 20 bytes longs, or five 32-bit words.
Type of Service—The TOS field was intended to define different ways of prioritizing packet forwarding. The flags, as defined in the IPv4 standard, are of historical interest only. IP routing uses a best-effort priority. The field is in the process of being redefined by the standards committees to define quality of service (QoS) under a differentiated services model (DiffServ).
Datagram Length—The length field contains the total number of bytes in the packet.
Packet ID—The packet ID is used to identify incoming packets as being fragments originally belonging to a single datagram sent from the source host.
Fragmentation Flags—This field is 3 bits long. One bit is unused. One bit, Don't Fragment, indicates that the packet must not be fragmented. One bit, More Fragments, indicates that in a series of fragments, more fragments are to follow.
Fragment Offset—The Fragment Offset field is 13 bits wide, which is a small field not even 2 bytes wide. The largest packet size is 65535 bytes long (including the headers), and that requires 16 bits to represent the size in bytes as an unsigned value. Because 13 bits are available for the field, the offset into the original, nonfragmented, packet's data must be expressed in some larger unit than a byte. So, the unit size is 8-byte chunks, or 64 bits.
Time to Live—The TTL field specifies how many hops, or routers, the packet can pass through in transit before being dropped.
Protocol—The protocol field specifies the transport protocol, TCP or UDP usually, the IP packet encapsulates. The protocol type can also be ICMP or IGMP. Although these two protocols are part of Layer 3, just as IP is, they are encapsulated in an IP header.)
Header Checksum—The checksum field is used to verify that the packet header arrived uncorrupted.
Source Address—This field contains the originating sender's IP address.
Destination Address—This field contains the destination host's IP address.
IP Options—This field is variable length and can range from 0 to 11 bytes long. IP options are almost never specified. Some routers and firewalls drop packets containing any options. Because the field is optional, and most packets don't contain the field, most IP headers are 20 bytes long.
Padding—This field is used to pad the final word in the packet containing options to a 32-bit boundary.
IP Message Types: ICMP
An ICMP packet is a network layer, IP control, and status message. As shown in Figure 1.6, its header contains the ICMP message type and subtype code. An ICMP message type indicates whether the packet is a command, a response to a command, status information, or an error condition. Individual ICMP messages do not contain source and destination ports. They are not sent between programs, but between IP layers on the endpoint hosts and intermediate routers.
Figure 1.6. ICMP Header.
Table 1.3 lists the common ICMP message types of most interest to a small site.
Table 1.3 Common ICMP Message Types
){kind=link}
){kind=link}
An example ICMP message is an error status message. If you attempt to query a remote DNS server by sending a message to the server's UDP port 53, and a DNS server isn't running on the remote host, the remote host would normally return an ICMP type 3 error message indicating that the service doesn't exist. The fields of interest in the packet header are shown in Figure 1.7.
){kind=link}
Figure 1.7. Incoming ICMP error message.
ICMP Error Messages with UDP and TCP
UDP port access errors are indicated with ICMP error messages. TCP port access errors are indicated by TCP RST messages. Sending an ICMP error message in response to a TCP port access error is optional. Firewalls can modify the default response to both UDP and TCP access errors.
IP Message Types: UDP
UDP is a stateless (that is, connectionless) and unreliable transport delivery protocol. A program sends a UDP message, which may or may not be received or responded to. No acknowledgment of receipt is returned by the UDP protocol. No flow control is provided, so a UDP datagram is silently dropped if it can't be processed along the way.
As shown in Figure 1.8, a UDP packet header contains the source and destination service port numbers, the UDP packet length in bytes, and a checksum of the packet.
){kind=link}
Figure 1.8. UDP Header.
Unreliable UDP?
UDP is referred to as an unreliable datagram service. Unreliable doesn't carry any negative connotations as to UDP's usability. Unreliable in this case means that no effort is made to ensure proper delivery at the UDP level. If reliability is required, it must be guaranteed at the application layer. As a result, without the reliable, connection-oriented overhead of TCP, UDP-based data transfer is several times faster than TCP-based data transfer. Consequently, UDP is often used to transport voice and video data streams. Higher layer multimedia data services often prefer disregarding a few dropped UDP packets over waiting for TCP retransmission.
As an example, your machine could periodically attempt to contact a remote network time server. Internet time servers are assigned UDP service port 123. The time server will return the current time of day. Your system could update its system clock with the information from the more accurate network time server. If the exchange is unsuccessful because the time server isn't running on the remote machine or the remote machine is down at the time, an ICMP type 3 error message, Service or Host Not Available, is returned.
As shown in Figure 1.9, the client program on your system initiates the request. An unprivileged port is assigned to the request. An outgoing UDP request packet is constructed with the unprivileged port as the source port. The destination port is the well-known time service port, 123.
){kind=link}
Figure 1.9. UDP request and response.
The time server responds with a UDP packet containing the current time. An incoming UDP response packet will arrive from the time server's IP address from source port 123, addressed to your IP address and the unprivileged destination port you initially provided.
IP Message Types: TCP
The vast majority of historically common network services run over TCP. Messages are sent reliably in both directions as part of an ongoing connection between two programs—without error, without loss or duplication, and delivered in order. Every TCP segment is acknowledged after receipt. Every TCP segment is identified by a unique sequence number. Flag bits are used to define the state of the connection.
If an IP-encapsulated TCP segment will be larger than the maximum transmission unit (MTU) of the underlying network, the segment is broken up into fragments. (Because most networks are Ethernet networks, the MTU is 1500 bytes maximum per Ethernet frame.) The fragments are identified as belonging to a particular segment and sent individually, to be reconstructed into the original TCP segment by the final destination computer.
When a client program initiates a connection to a server, a port is selected from the unprivileged pool on the client's end. The combination of the client's IP address and port number defines the client's socket. On the server side, the combination of host IP address and the server's famous port number forms the server's socket. The connection between client and server is uniquely defined by this socket pair.
Each individual connection between a given client and server, possibly just one in a set of simultaneous connections to that server (for example, a web server), is uniquely identified by both the source address and port number of the client in conjunction with the server's IP address and assigned port number.
As shown in Figure 1.10, a TCP packet header contains the source and destination service ports, and sequence and acknowledgment numbers and control flags used to create and maintain a reliable virtual circuit, or ongoing two-way connection.
){kind=link}
Figure 1.10. TCP Header.
A Typical TCP Connection: Visiting a Remote Web Site
As an illustration, a common TCP connection example is going to a web site through your browser (connecting to a web server). This section illustrates the aspects of connection establishment and ongoing communication that will be relevant to IP packet filtering in later chapters.
What happens? As shown in Figure 1.11, a web server is running on a machine somewhere, waiting for a connection request on TCP service port 80. You click on the link for a URL in Netscape. Part of the URL is parsed into a hostname; the hostname is translated into the web server's IP address; and your browser is assigned an unprivileged port (for example, TCP port 14000) for the connection. An HTTP message for the web server is constructed. It's encapsulated in a TCP message, wrapped in an IP packet header, and sent out. For our purposes, the header contains the fields shown in Figure 1.11.
){kind=link}
Figure 1.11. TCP client connection request.
Additional information is included in the header that isn't visible at the packet-filtering level. Nevertheless, describing the sequence numbers associated with the SYN and ACK flags helps clarify what's happening during the three-way handshake. When the client program sends its first connection request message, the SYN flag is accompanied by a synchronization sequence number. The client is requesting a connection with the server and passes along a starting sequence number it will use as the starting point to number all the rest of the data bytes the client will send.
The packet is received at the server machine. It's sent to service port 80. The server is listening to port 80, so it's notified of an incoming connection request (the SYN connection synchronization request flag) from the source IP address and port socket pair (<your IP address>, 14000). The server allocates a new socket on its end, (<web server IP address>, 80), and associates it with the client socket.
The web server responds with an acknowledgment (ACK) to the SYN message, along with its own synchronization request (SYN), as shown in Figure 1.12. The connection is now half open.
){kind=link}
Figure 1.12. TCP server connection request acknowledgment.
Two fields not visible to the packet-filtering level are included in the SYN-ACK header. Along with the ACK flag, the server includes the client's sequence number incremented by the number of contiguous data bytes received. The purpose of the acknowledgment is to acknowledge the data the client referred to by its sequence number. The server acknowledges this by incrementing the client's sequence number, effectively saying it received the data, and sequence number + 1 is the next data byte the server expects to receive. The client is free to throw its copy of the original SYN message away now that the server has acknowledged receipt of it.
The server also sets the SYN flag in its first message. As with the client's first message, the SYN flag is accompanied by a synchronization sequence number. The server is passing along its own starting sequence number for its half of the connection.
This first message is the only message the server will send with the SYN flag set. This and all subsequent messages have the ACK flag set. The presence of the ACK flag in all server messages, as compared to the lack of an ACK flag in the client's first message, will be a critical difference when we get to the information available for constructing a firewall.
Your machine receives this message and replies with its own acknowledgment, after which the connection is established. Figure 1.13 shows a graphic representation. From here on, both the client and server set the ACK flag. The SYN flag won't be set again by either program.
){kind=link}
Figure 1.13. TCP connection establishment.
With each acknowledgment, the client and server programs increment their partner process's sequence number by the amount of contiguous data received, plus one, indicating receipt of that many bytes of data, and indicating the next data byte in the stream the program expects to receive.
As your browser receives the web page, your machine receives data messages from the web server with packet headers, as shown in Figure 1.14.
){kind=link}
Figure 1.14. Ongoing TCP server-to-client connection.
TCP State Flags
From a basic firewalling perspective, the SYN and ACK flags are often the only two TCP state flags inspected. In today's world, all of the flags are important. The flags are
SYN—Synchronize data byte sequence number—The SYN flag is set in the first packet sent by both the client and server. Each byte of data sent is sequentially numbered. (Note that the initial sequence number should be random and refers to the first byte of data sent, not including the header. Each subsequent data byte is incrementally numbered from the initial sequence number.)
-
ACK—Acknowledge the last contiguous data byte received—The ACK flag indicates that the Acknowledgement Sequence number in the TCP header is valid and contains the sequence number of the next data byte expected.
-
RST—Reset connection. The RST flag is sent by either end to indicate an unrecoverable error condition. Both sides immediately end the connection, release any resources allocated to the connection, and drop any further packets in transit.
-
PSH—Push data as received. The PSH flag indicates that the receiver should deliver the data to the application immediately, rather than buffering the data. PSH is used for interactive applications such as telnet.
-
URG—Urgent data delivery. The URG flag indicates that the data should be delivered immediately, such as with realtime event notifications. The Urgent Pointer field in the TCP header contains the offset of the data byte following the urgent data.
-
FIN—Finished sending data. The data sender sets the FIN flag when its data transmission is complete. It then waits for the receiver to acknowledge receipt of the final data and return a FIN message itself, at which point the data sender acknowledges receipt of the final FIN from the receiver and terminates its end of the connection. The receiver terminates its end of the connection upon receipt of the final ACK. (Either the client or the server can initiate connection termination.) Figure 1.15 shows the steps in TCP connection tear-down.
-
RES—Reserved flags. Two bits of the TCP flag byte are unused and must be zero.
){kind=link}
Figure 1.15. TCP connection tear-down.