Security Considerations for IP Fragment Filtering
RFC 1858

Document Type RFC - Informational (October 1995; No errata)
Updated by RFC 3128
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html
Stream Legacy state (None)
Document shepherd No shepherd assigned
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
                                                              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.


   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

Ziemba, Reed & Traina        Informational                      [Page 2]
RFC 1858    Security Considerations - IP Fragment Filtering October 1995
Show full document text