A more general solution to filter connection oriented services is called stateful inspection. It was suggested to introduce some state into packet filtering process. Consequently, the resulting packet filter rules are dy- namic and context-sensitive, the first attribute also being reflected in the term dynamic packet filtering that is sometimes used as a synonym for stateful inspection.
Stateful inspection (or dynamic packet filtering) looks at the same header information as static packet filtering does, but can also peek into the payload data where the transport and application layer data usually appears. More importantly, stateful inspection maintains state information about passed IP packets. It compares the first packet in a TCP connection to the packet filter rules, and if the packet is permitted, state information is added to an internal database. Think of this state information representing an internal virtual circuit in the firewall on top of the transport layer association. This information permits subsequent packets in that association to pass quickly through the firewall. If the rules for a specific type of service require examining application data, the part of each packet must still be examined.
For example, a dynamic packet filtering device can react on seeing an FTP PORT command by creating a dynamic rule permitting a TCP connection back from the FTP server to that particular port number of the client side. Logging, or authentication as required by the rules, generally occurs at the application layer. Although the opportunity for better logging is present, stateful inspection firewalls typically only log the source and destination IP addresses and port numbers, similar to logging with a packet filter or screening router.
In spite of the fact that you can introduce state information to improve the capabilities of a packet filtering device, the problem remains that there is no such thing as an association between a data stream and a previously authenticated and authorized user. To make things worse, there is no such thing as a user on the Internet layer where packet filtering occurs. Consequently, true firewalls must operate above the Internet layer, typically at the transport layer. There are also further problems with stateful packet filtering:
State tracking of a packet filter provides the ability to do things that you cannot do therewise, but it also adds complications. First, the packet filter has to keep track of the state. This increases the load on the packet filter, opens it to a number of denial of service attacks, and means that if the router reboots, packets may be denied when they should have been accepted. If a packet may go through redundant packet filters, they all need to have the same state information. There are protocols for exchanging this informa- tion, but it's still a tricky business. If you have redundant routers simultaneously, the state information needs to be transferred between them almost continously, or the response packet may come through before the state is updated.
Second, the packet filter has to keep track of state without any guarantee that there is ever going to be a response packet. Not all UDP packets have responses. At some point, the packet filter needs to give up and to get rid of the rule that will allow the response. If the packet filter gives up early, it will deny packets that should have been accepted, causing delays and unneeded network tra±c. If the router keeps the rule too long, the load on the router will be unnecessarily high, and there is an increased chance that packets will be accepted when they should have been denied. Some protocol specifications provide guidelines, but those are not necessarily useful. For instance, DNS (Domain Name Service) replies are supposed to arrive within 5 seconds, but reply times for name service queries across the Internet can be as high as 15 seconds. An implementation of the protocol specification will almost deny a response that you wanted to accepted.