Home > Articles > Security > Network Security

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

Figure 1.15. TCP connection tear-down.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020