Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6274

Security Assessment of the Internet Protocol Version 4

Pages: 75
Informational
Errata
Part 4 of 5 – Pages 48 to 61
First   Prev   Next

Top   ToC   RFC6274 - Page 48   prevText

4. Internet Protocol Mechanisms

4.1. Fragment Reassembly

To accommodate networks with different Maximum Transmission Units (MTUs), the Internet Protocol provides a mechanism for the fragmentation of IP packets by end-systems (hosts) and/or intermediate-systems (routers). Reassembly of fragments is performed only by the end-systems. [Cerf1974] provides the rationale for why packet reassembly is not performed by intermediate-systems. During the last few decades, IP fragmentation and reassembly has been exploited in a number of ways, to perform actions such as evading NIDSs, bypassing firewall rules, and performing DoS attacks. [Bendi1998] and [Humble1998] are examples of the exploitation of these issues for performing DoS attacks. [CERT1997] and [CERT1998b] document these issues. [Anderson2001] is a survey of fragmentation attacks. [US-CERT2001] is an example of the exploitation of IP fragmentation to bypass firewall rules. [CERT1999] describes the implementation of fragmentation attacks in Distributed Denial-of-Service (DDoS) attack tools. The problem with IP fragment reassembly basically has to do with the complexity of the function, in a number of aspects: o Fragment reassembly is a stateful operation for a stateless protocol (IP). The IP module at the host performing the reassembly function must allocate memory buffers both for temporarily storing the received fragments and to perform the reassembly function. Attackers can exploit this fact to exhaust memory buffers at the system performing the fragment reassembly. o The fragmentation and reassembly mechanisms were designed at a time in which the available bandwidths were very different from the bandwidths available nowadays. With the current available bandwidths, a number of interoperability problems may arise, and these issues may be intentionally exploited by attackers to perform DoS attacks. o Fragment reassembly must usually be performed without any knowledge of the properties of the path the fragments follow. Without this information, hosts cannot make any educated guess on how long they should wait for missing fragments to arrive.
Top   ToC   RFC6274 - Page 49
   o  The fragment reassembly algorithm, as described by the IETF
      specifications, is ambiguous, and allows for a number of
      interpretations, each of which has found place in different TCP/IP
      stack implementations.

   o  The reassembly process is somewhat complex.  Fragments may arrive
      out of order, duplicated, overlapping each other, etc.  This
      complexity has lead to numerous bugs in different implementations
      of the IP protocol.

4.1.1. Security Implications of Fragment Reassembly

4.1.1.1. Problems Related to Memory Allocation
When an IP datagram is received by an end-system, it will be temporarily stored in system memory, until the IP module processes it and hands it to the protocol machine that corresponds to the encapsulated protocol. In the case of fragmented IP packets, while the IP module may perform preliminary processing of the IP header (such as checking the header for errors and processing IP options), fragments must be kept in system buffers until all fragments are received and are reassembled into a complete Internet datagram. As mentioned above, because the Internet layer will not usually have information about the characteristics of the path between the system and the remote host, no educated guess can be made on the amount of time that should be waited for the other fragments to arrive. Therefore, the specifications recommend to wait for a period of time that is acceptable for virtually all the possible network scenarios in which the protocols might operate. After that time has elapsed, all the received fragments for the corresponding incomplete packet are discarded. The original IP Specification, RFC 791 [RFC0791], states that systems should wait for at least 15 seconds for the missing fragments to arrive. Systems that follow the "Example Reassembly Procedure" described in Section 3.2 of RFC 791 may end up using a reassembly timer of up to 4.25 minutes, with a minimum of 15 seconds. Section 3.3.2 ("Reassembly") of RFC 1122 corrected this advice, stating that the reassembly timeout should be a fixed value between 60 and 120 seconds.
Top   ToC   RFC6274 - Page 50
   However, the longer the system waits for the missing fragments to
   arrive, the longer the corresponding system resources must be tied to
   the corresponding packet.  The amount of system memory is finite, and
   even with today's systems, it can still be considered a scarce
   resource.

   An attacker could take advantage of the uncomfortable situation the
   system performing fragment reassembly is in, by sending forged
   fragments that will never reassemble into a complete datagram.  That
   is, an attacker would send many different fragments, with different
   IP IDs, without ever sending all the necessary fragments that would
   be needed to reassemble them into a full IP datagram.  For each of
   the fragments, the IP module would allocate resources and tie them to
   the corresponding fragment, until the reassembly timer for the
   corresponding packet expires.

   There are some implementation strategies which could increase the
   impact of this attack.  For example, upon receipt of a fragment, some
   systems allocate a memory buffer that will be large enough to
   reassemble the whole datagram.  While this might be beneficial in
   legitimate cases, this just amplifies the impact of the possible
   attacks, as a single small fragment could tie up memory buffers for
   the size of an extremely large (and unlikely) datagram.  The
   implementation strategy suggested in RFC 815 [RFC0815] leads to such
   an implementation.

   The impact of the aforementioned attack may vary depending on some
   specific implementation details:

   o  If the system does not enforce limits on the amount of memory that
      can be allocated by the IP module, then an attacker could tie all
      system memory to fragments, at which point the system would become
      unusable, perhaps crashing.

   o  If the system enforces limits on the amount of memory that can be
      allocated by the IP module as a whole, then, when this limit is
      reached, all further IP packets that arrive would be discarded,
      until some fragments time out and free memory is available again.

   o  If the system enforces limits on the amount memory that can be
      allocated for the reassembly of fragments, then, when this limit
      is reached, all further fragments that arrive would be discarded,
      until some fragment(s) time out and free memory is available
      again.
Top   ToC   RFC6274 - Page 51
4.1.1.2. Problems That Arise from the Length of the IP Identification Field
The Internet Protocols are currently being used in environments that are quite different from the ones in which they were conceived. For instance, the availability of bandwidth at the time the Internet Protocol was designed was completely different from the availability of bandwidth in today's networks. The Identification field is a 16-bit field that is used for the fragmentation and reassembly function. In the event a datagram gets fragmented, all the corresponding fragments will share the same {Source Address, Destination Address, Protocol, Identification number} four-tuple. Thus, the system receiving the fragments will be able to uniquely identify them as fragments that correspond to the same IP datagram. At a given point in time, there must be at most only one packet in the network with a given four-tuple. If not, an Identification number "collision" might occur, and the receiving system might end up "mixing" fragments that correspond to different IP datagrams which simply reused the same Identification number. For example, sending over a 1 Gbit/s path a continuous stream of (UDP) packets of roughly 1 kb size that all get fragmented into two equally sized fragments of 576 octets each (minimum reassembly buffer size) would repeat the IP Identification values within less than 0.65 seconds (assuming roughly 10% link layer overhead); with shorter packets that still get fragmented, this figure could easily drop below 0.4 seconds. With a single IP packet dropped in this short time frame, packets would start to be reassembled wrongly and continuously once in such interval until an error detection and recovery algorithm at an upper layer lets the application back out. For each group of fragments whose Identification numbers "collide", the fragment reassembly will lead to corrupted packets. The IP payload of the reassembled datagram will be handed to the corresponding upper-layer protocol, where the error will (hopefully) be detected by some error detecting code (such as the TCP checksum) and the packet will be discarded. An attacker could exploit this fact to intentionally cause a system to discard all or part of the fragmented traffic it gets, thus performing a DoS attack. Such an attacker would simply establish a flow of fragments with different IP Identification numbers, to trash all or part of the IP Identification space. As a result, the receiving system would use the attacker's fragments for the reassembly of legitimate datagrams, leading to corrupted packets which would later (and hopefully) get dropped.
Top   ToC   RFC6274 - Page 52
   In most cases, use of a long fragment timeout will benefit the
   attacker, as forged fragments will keep the IP Identification space
   trashed for a longer period of time.

4.1.1.3. Problems That Arise from the Complexity of the Reassembly Algorithm
As IP packets can be duplicated by the network, and each packet may take a different path to get to the destination host, fragments may arrive not only out of order and/or duplicated but also overlapping. This means that the reassembly process can be somewhat complex, with the corresponding implementation being not specifically trivial. [Shannon2001] analyzes the causes and attributes of fragment traffic measured in several types of WANs. During the years, a number of attacks have exploited bugs in the reassembly function of several operating systems, producing buffer overflows that have led, in most cases, to a crash of the attacked system.
4.1.1.4. Problems That Arise from the Ambiguity of the Reassembly Process
Network Intrusion Detection Systems (NIDSs) typically monitor the traffic on a given network with the intent of identifying traffic patterns that might indicate network intrusions. In the presence of IP fragments, in order to detect illegitimate activity at the transport or application layers (i.e., any protocol layer above the network layer), a NIDS must perform IP fragment reassembly. In order to correctly assess the traffic, the result of the reassembly function performed by the NIDS should be the same as that of the reassembly function performed by the intended recipient of the packets. However, a number of factors make the result of the reassembly process ambiguous: o The IETF specifications are ambiguous as to what should be done in the event overlapping fragments were received. Thus, in the presence of overlapping data, the system performing the reassembly function is free to honor either the first set of data received, the latest copy received, or any other copy received in between.
Top   ToC   RFC6274 - Page 53
   o  As the specifications do not enforce any specific fragment timeout
      value, different systems may choose different values for the
      fragment timeout.  This means that given a set of fragments
      received at some specified time intervals, some systems will
      reassemble the fragments into a full datagram, while others may
      timeout the fragments and therefore drop them.

   o  As mentioned before, as the fragment buffers get full, a DoS
      condition will occur unless some action is taken.  Many systems
      flush part of the fragment buffers when some threshold is reached.
      Thus, depending on fragment load, timing issues, and flushing
      policy, a NIDS may get incorrect assumptions about how (and if)
      fragments are being reassembled by their intended recipient.

   As originally discussed by [Ptacek1998], these issues can be
   exploited by attackers to evade intrusion detection systems.

   There exist freely available tools to forcefully fragment IP
   datagrams so as to help evade Intrusion Detection Systems.  Frag
   router [Song1999] is an example of such a tool; it allows an attacker
   to perform all the evasion techniques described in [Ptacek1998].
   Ftester [Barisani2006] is a tool that helps to audit systems
   regarding fragmentation issues.

4.1.1.5. Problems That Arise from the Size of the IP Fragments
One approach to fragment filtering involves keeping track of the results of applying filter rules to the first fragment (i.e., the fragment with a Fragment Offset of 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 Identification number. When the initial 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 Fragment Offset come in, look up the list element with a matching Source Address/Destination Address/Protocol/ Identification and apply the stored result (pass or block). When a fragment with a zero MF bit is seen, free the list element. Unfortunately, the rules of this type of packet filter can usually be bypassed. [RFC1858] describes the details of the involved technique.

4.1.2. Possible Security Improvements

4.1.2.1. Memory Allocation for Fragment Reassembly
A design choice usually has to be made as to how to allocate memory to reassemble the fragments of a given packet. There are basically two options:
Top   ToC   RFC6274 - Page 54
   o  Upon receipt of the first fragment, allocate a buffer that will be
      large enough to concatenate the payload of each fragment.

   o  Upon receipt of the first fragment, create the first node of a
      linked list to which each of the following fragments will be
      linked.  When all fragments have been received, copy the IP
      payload of each of the fragments (in the correct order) to a
      separate buffer that will be handed to the protocol being
      encapsulated in the IP payload.

   While the first of the choices might seem to be the most
   straightforward, it implies that even when a single small fragment of
   a given packet is received, the amount of memory that will be
   allocated for that fragment will account for the size of the complete
   IP datagram, thus using more system resources than what is actually
   needed.

   Furthermore, the only situation in which the actual size of the whole
   datagram will be known is when the last fragment of the packet is
   received first, as that is the only packet from which the total size
   of the IP datagram can be asserted.  Otherwise, memory should be
   allocated for the largest possible packet size (65535 bytes).

   The IP module should also enforce a limit on the amount of memory
   that can be allocated for IP fragments, as well as a limit on the
   number of fragments that at any time will be allowed in the system.
   This will basically limit the resources spent on the reassembly
   process, and prevent an attacker from trashing the whole system
   memory.

   Furthermore, the IP module should keep a different buffer for IP
   fragments than for complete IP datagrams.  This will basically
   separate the effects of fragment attacks on non-fragmented traffic.
   Most TCP/IP implementations, such as that in Linux and those in BSD-
   derived systems, already implement this.

   [Jones2002] analyzes the amount of memory that may be needed for the
   fragment reassembly buffer depending on a number of network
   characteristics.

4.1.2.2. Flushing the Fragment Buffer
In the case of those attacks that aim to consume the memory buffers used for fragments, and those that aim to cause a collision of IP Identification numbers, there are a number of countermeasures that can be implemented.
Top   ToC   RFC6274 - Page 55
   Even with these countermeasures in place, there is still the issue of
   what to do when the buffer pool used for IP fragments gets full.
   Basically, if the fragment buffer is full, no instance of
   communication that relies on fragmentation will be able to progress.

   Unfortunately, there are not many options for reacting to this
   situation.  If nothing is done, all the instances of communication
   that rely on fragmentation will experience a denial of service.
   Thus, the only thing that can be done is flush all or part of the
   fragment buffer, on the premise that legitimate traffic will be able
   to make use of the freed buffer space to allow communication flows to
   progress.

   There are a number of factors that should be taken into consideration
   when flushing the fragment buffers.  First, if a fragment of a given
   packet (i.e., fragment with a given Identification number) is
   flushed, all the other fragments that correspond to the same datagram
   should be flushed.  As in order for a packet to be reassembled all of
   its fragments must be received by the system performing the
   reassembly function, flushing only a subset of the fragments of a
   given packet would keep the corresponding buffers tied to fragments
   that would never reassemble into a complete datagram.  Additionally,
   care must be taken so that, in the event that subsequent buffer
   flushes need to be performed, it is not always the same set of
   fragments that get dropped, as such a behavior would probably cause a
   selective DoS to the traffic flows to which that set of fragments
   belongs.

   Many TCP/IP implementations define a threshold for the number of
   fragments that, when reached, triggers a fragment-buffer flush.  Some
   systems flush 1/2 of the fragment buffer when the threshold is
   reached.  As mentioned before, the idea of flushing the buffer is to
   create some free space in the fragment buffer, on the premise that
   this will allow for new and legitimate fragments to be processed by
   the IP module, thus letting communication survive the overwhelming
   situation.  On the other hand, the idea of flushing a somewhat large
   portion of the buffer is to avoid flushing always the same set of
   packets.

4.1.2.3. A More Selective Fragment Buffer Flushing Strategy
One of the difficulties in implementing countermeasures for the fragmentation attacks described throughout Section 4.1 is that it is difficult to perform validation checks on the received fragments. For instance, the fragment on which validity checks could be performed, the first fragment, may be not the first fragment to arrive at the destination host.
Top   ToC   RFC6274 - Page 56
   Fragments cannot only arrive out of order because of packet
   reordering performed by the network, but also because the system (or
   systems) that fragmented the IP datagram may indeed transmit the
   fragments out of order.  A notable example of this is the Linux
   TCP/IP stack, which transmits the fragments in reverse order.

   This means that we cannot enforce checks on the fragments for which
   we allocate reassembly resources, as the first fragment we receive
   for a given packet may be some other fragment than the first one (the
   one with an Fragment Offset of 0).

   However, at the point in which we decide to free some space in the
   fragment buffer, some refinements can be done to the flushing policy.
   The first thing we would like to do is to stop different types of
   traffic from interfering with each other.  This means, in principle,
   that we do not want fragmented UDP traffic to interfere with
   fragmented TCP traffic.  In order to implement this traffic
   separation for the different protocols, a different fragment buffer
   pool would be needed, in principle, for each of the 256 different
   protocols that can be encapsulated in an IP datagram.

   We believe a trade-off is to implement two separate fragment buffers:
   one for IP datagrams that encapsulate IPsec packets and another for
   the rest of the traffic.  This basically means that traffic not
   protected by IPsec will not interfere with those flows of
   communication that are being protected by IPsec.

   The processing of each of these two different fragment buffer pools
   would be completely independent from each other.  In the case of the
   IPsec fragment buffer pool, when the buffers needs to be flushed, the
   following refined policy could be applied:

   o  First, for each packet for which the IPsec header has been
      received, check that the Security Parameters Index (SPI) field of
      the IPsec header corresponds to an existing IPsec Security
      Association (SA), and probably also check that the IPsec sequence
      number is valid.  If the check fails, drop all the fragments that
      correspond to this packet.

   o  Second, if still more fragment buffers need to be flushed, drop
      all the fragments that correspond to packets for which the full
      IPsec header has not yet been received.  The number of packets for
      which this flushing is performed depends on the amount of free
      space that needs to be created.

   o  Third, if after flushing packets with invalid IPsec information
      (First step), and packets on which validation checks could not be
      performed (Second step), there is still not enough space in the
Top   ToC   RFC6274 - Page 57
      fragment buffer, drop all the fragments that correspond to packets
      that passed the checks of the first step, until the necessary free
      space is created.

   The rationale behind this policy is that, at the point of flushing
   fragment buffers, we prefer to keep those packets on which we could
   successfully perform a number of validation checks, over those
   packets on which those checks failed, or the checks could not even be
   performed.

   By checking both the IPsec SPI and the IPsec sequence number, it is
   virtually impossible for an attacker that is off-path to perform a
   DoS attack to communication flows being protected by IPsec.

   Unfortunately, some IP implementations (such as that in Linux
   [Linux]), when performing fragmentation, send the corresponding
   fragments in reverse order.  In such cases, at the point of flushing
   the fragment buffer, legitimate fragments will receive the same
   treatment as the possible forged fragments.

   This refined flushing policy provides an increased level of
   protection against this type of resource exhaustion attack, while not
   making the situation of out-of-order IPsec-secured traffic worse than
   with the simplified flushing policy described in the previous
   section.

4.1.2.4. Reducing the Fragment Timeout
RFC 1122 [RFC1122] states that the reassembly timeout should be a fixed value between 60 and 120 seconds. The rationale behind these long timeout values is that they should accommodate any path characteristics, such as long-delay paths. However, it must be noted that this timer is really measuring inter-fragment delays, or, more specifically, fragment jitter. If all fragments take paths of similar characteristics, the inter- fragment delay will usually be, at most, a few seconds. Nevertheless, even if fragments take different paths of different characteristics, the recommended 60 to 120 seconds are, in practice, excessive. Some systems have already reduced the fragment timeout to 30 seconds [Linux]. The fragment timeout could probably be further reduced to approximately 15 seconds; although further research on this issue is necessary.
Top   ToC   RFC6274 - Page 58
   It should be noted that in network scenarios of long-delay and high-
   bandwidth (usually referred to as "Long-Fat Networks"), using a long
   fragment timeout would likely increase the probability of collision
   of IP ID numbers.  Therefore, in such scenarios it is highly
   desirable to avoid the use of fragmentation with techniques such as
   PMTUD [RFC1191] or PLPMTUD [RFC4821].

4.1.2.5. Countermeasure for Some NIDS Evasion Techniques
[Shankar2003] introduces a technique named "Active Mapping" that prevents evasion of a NIDS by acquiring sufficient knowledge about the network being monitored, to assess which packets will arrive at the intended recipient, and how they will be interpreted by it. [Novak2005] describes some techniques that are applied by the Snort [Snort] NIDS to avoid evasion.
4.1.2.6. Countermeasure for Firewall-Rules Bypassing
One of the classical techniques to bypass firewall rules involves sending packets in which the header of the encapsulated protocol is fragmented. Even when it would be legal (as far as the IETF specifications are concerned) to receive such a packets, the MTUs of the network technologies used in practice are not that small to require the header of the encapsulated protocol to be fragmented (e.g., see [RFC2544]). Therefore, the system performing reassembly should drop all packets which fragment the upper-layer protocol header, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). Additionally, given that many middle-boxes such as firewalls create state according to the contents of the first fragment of a given packet, it is best that, in the event an end-system receives overlapping fragments, it honors the information contained in the fragment that was received first. RFC 1858 [RFC1858] describes the abuse of IP fragmentation to bypass firewall rules. RFC 3128 [RFC3128] corrects some errors in RFC 1858.

4.2. Forwarding

4.2.1. Precedence-Ordered Queue Service

Section 5.3.3.1 of RFC 1812 [RFC1812] states that routers should implement precedence-ordered queue service. This means that when a packet is selected for output on a (logical) link, the packet of highest precedence that has been queued for that link is sent. Section 5.3.3.2 of RFC 1812 advises routers to default to maintaining strict precedence-ordered service.
Top   ToC   RFC6274 - Page 59
   Unfortunately, given that it is trivial to forge the IP precedence
   field of the IP header, an attacker could simply forge a high
   precedence number in the packets it sends to illegitimately get
   better network service.  If precedence-ordered queued service is not
   required in a particular network infrastructure, it should be
   disabled, and thus all packets would receive the same type of
   service, despite the values in their Type of Service or
   Differentiated Services fields.

   When precedence-ordered queue service is required in the network
   infrastructure, in order to mitigate the attack vector discussed in
   the previous paragraph, edge routers or switches should be configured
   to police and remark the Type of Service or Differentiated Services
   values, according to the type of service at which each end-system has
   been allowed to send packets.

   Bullet 4 of Section 5.3.3.3 of RFC 1812 states that routers "MUST NOT
   change precedence settings on packets it did not originate".
   However, given the security implications of the Precedence field, it
   is fair for routers, switches, or other middle-boxes, particularly
   those in the network edge, to overwrite the Type of Service (or
   Differentiated Services) field of the packets they are forwarding,
   according to a configured network policy (this is the specified
   behavior for DS domains [RFC2475]).

   Sections 5.3.3.1 and 5.3.6 of RFC 1812 state that if precedence-
   ordered queue service is implemented and enabled, the router "MUST
   NOT discard a packet whose precedence is higher than that of a packet
   that is not discarded".  While this recommendation makes sense given
   the semantics of the Precedence field, it is important to note that
   it would be simple for an attacker to send packets with forged high
   Precedence value to congest some internet router(s), and cause all
   (or most) traffic with a lower Precedence value to be discarded.

4.2.2. Weak Type of Service

Section 5.2.4.3 of RFC 1812 describes the algorithm for determining the next-hop address (i.e., the forwarding algorithm). Bullet 3, "Weak TOS", addresses the case in which routes contain a "type of service" attribute. It states that in case a packet contains a non- default TOS (i.e., 0000), only routes with the same TOS or with the default TOS should be considered for forwarding that packet. However, this means that if among the longest match routes for a given packet are routes with some TOS other than the one contained in the received packet, and no routes with the default TOS, the corresponding packet would be dropped. This may or may not be a desired behavior.
Top   ToC   RFC6274 - Page 60
   An alternative for the case in which among the "longest match" routes
   there are only routes with non-default type of service that do not
   match the TOS contained in the received packet, would be to use a
   route with any other TOS.  While this route would most likely not be
   able to address the type of service requested by packet, it would, at
   least, provide a "best effort" service.

   It must be noted that Section 5.3.2 of RFC 1812 allows routers to not
   honor the TOS field.  Therefore, the proposed alternative behavior is
   still compliant with the IETF specifications.

      While officially specified in the RFC series, TOS-based routing is
      not widely deployed in the Internet.

4.2.3. Impact of Address Resolution on Buffer Management

In the case of broadcast link-layer technologies, in order for a system to transfer an IP datagram it must usually first map an IP address to the corresponding link-layer address (for example, by means of the Address Resolution Protocol (ARP) [RFC0826]) . This means that while this operation is being performed, the packets that would require such a mapping would need to be kept in memory. This may happen both in the case of hosts and in the case of routers. This situation might be exploited by an attacker, which could send a large amount of packets to a non-existent host that would supposedly be directly connected to the attacked router. While trying to map the corresponding IP address into a link-layer address, the attacked router would keep in memory all the packets that would need to make use of that link-layer address. At the point in which the mapping function times out, depending on the policy implemented by the attacked router, only the packet that triggered the call to the mapping function might be dropped. In that case, the same operation would be repeated for every packet destined to the non-existent host. Depending on the timeout value for the mapping function, this situation might lead the router to run out of free buffer space, with the consequence that incoming legitimate packets would have to be dropped, or that legitimate packets already stored in the router's buffers might get dropped. Both of these situations would lead either to a complete DoS or to a degradation of the network service. One countermeasure to this problem would be to drop, at the point the mapping function times out, all the packets destined to the address that timed out. In addition, a "negative cache entry" might be kept in the module performing the matching function, so that for some amount of time, the mapping function would return an error when the IP module requests to perform a mapping for some address for which the mapping has recently timed out.
Top   ToC   RFC6274 - Page 61
      A common implementation strategy for routers is that when a packet
      is received that requires an ARP resolution to be performed before
      the packet can be forwarded, the packet is dropped and the router
      is then engaged in the ARP procedure.

4.2.4. Dropping Packets

In some scenarios, it may be necessary for a host or router to drop packets from the output queue. In the event that one of such packets happens to be an IP fragment, and there were other fragments of the same packet in the queue, those other fragments should also be dropped. The rationale for this policy is that it is nonsensical to spend system resources on those other fragments, because, as long as one fragment is missing, it will be impossible for the receiving system to reassemble them into a complete IP datagram. Some systems have been known to drop just a subset of fragments of a given datagram, leading to a denial-of-service condition, as only a subset of all the fragments of the packets were actually transferred to the next hop.


(page 61 continued on part 5)

Next Section