Security Considerations for IP Fragment Filtering
RFC 1858
Document | Type |
RFC - Informational
(October 1995; No errata)
Updated by RFC 3128
Was draft-rfced-info-ip-frag-sec (individual)
|
|
---|---|---|---|
Authors | Darren Reed , Paul Traina , Paul Ziemba | ||
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 1858 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group G. Ziemba Request for Comments: 1858 Alantec Category: Informational D. Reed Cybersource P. Traina cisco Systems October 1995 Security Considerations for IP Fragment Filtering Status of This Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract IP fragmentation can be used to disguise TCP packets from IP filters used in routers and hosts. This document describes two methods of attack as well as remedies to prevent them. 1. Background System administrators rely on manufacturers of networking equipment to provide them with packet filters; these filters are used for keeping attackers from accessing private systems and information, while permitting friendly agents to transfer data between private nets and the Internet. For this reason, it is important for network equipment vendors to anticipate possible attacks against their equipment and to implement robust mechanisms to deflect such attacks. The growth of the global Internet has brought with it an increase in "undesirable elements" manifested in antisocial behavior. Recent months have seen the use of novel attacks on Internet hosts, which have in some cases led to the compromise of sensitive data. Increasingly sophisticated attackers have begun to exploit the more subtle aspects of the Internet Protocol; fragmentation of IP packets, an important feature in heterogeneous internetworks, poses several potential problems which we explore here. Ziemba, Reed & Traina Informational [Page 1] RFC 1858 Security Considerations - IP Fragment Filtering October 1995 2. Filtering IP Fragments IP packet filters on routers are designed with a user interface that hides packet fragmentation from the administrator; conceptually, an IP filter is applied to each IP packet as a complete entity. One approach to fragment filtering, described by Mogul [1], involves keeping track of the results of applying filter rules to the first fragment (FO==0) and applying them to subsequent fragments of the same packet. The filtering module would maintain a list of packets indexed by the source address, destination address, protocol, and IP ID. When the initial (FO==0) fragment is seen, if the MF bit is set, a list item would be allocated to hold the result of filter access checks. When packets with a non-zero FO come in, look up the list element with a matching SA/DA/PROT/ID and apply the stored result (pass or block). When a fragment with a zero MF bit is seen, free the list element. Although this method (or some refinement of it) might successfully remove any trace of the offending whole packet, it has some difficulties. Fragments that arrive out of order, possibly because they traveled over different paths, violate one of the design assumptions, and undesired fragments can leak through as a result. Furthermore, if the filtering router lies on one of several parallel paths, the filtering module will not see every fragment and cannot guarantee complete fragment filtering in the case of packets that should be dropped. Fortunately, we do not need to remove all fragments of an offending packet. Since "interesting" packet information is contained in the headers at the beginning, filters are generally applied only to the first fragment. Non-first fragments are passed without filtering, because it will be impossible for the destination host to complete reassembly of the packet if the first fragment is missing, and therefore the entire packet will be discarded. The Internet Protocol allows fragmentation of packets into pieces so small as to be impractical because of data and computational overhead. Attackers can sometimes exploit typical filter behavior and the ability to create peculiar fragment sequences in order to sneak otherwise disallowed packets past the filter. In normal practice, such pathalogical fragmentation is never used, so it is safe to drop these fragments without danger of preventing normal operation. Ziemba, Reed & Traina Informational [Page 2] RFC 1858 Security Considerations - IP Fragment Filtering October 1995 3. Tiny Fragment Attack With many IP implementations it is possible to impose an unusually small fragment size on outgoing packets. If the fragment size is made small enough to force some of a TCP packet's TCP header fieldsShow full document text