ICMP Security Failures Messages

Error Procedures

   As is usual with ICMP messages, upon receipt of one of these error
   messages that is uninterpretable or otherwise contains an error, no
   ICMP error message is sent in response.  Instead, the message is
   silently discarded.  However, for diagnosis of problems, a node
   SHOULD provide the capability of logging the error, including the
   contents of the silently discarded datagram, and SHOULD record the
   event in a statistics counter.

   On receipt, special care MUST be taken that the ICMP message actually
   includes information that matches a previously sent IP datagram.
   Otherwise, this might provide an opportunity for a denial of service
   attack.

   The sending implementation MUST be able to limit the rate at which
   these messages are generated.  The rate limit parameters SHOULD be
   configurable.  How the limits are applied (such as, by destination or
   per interface) is left to the implementor's discretion. 

 Security Considerations

   When a prior Security Association between the parties has not
   expired, these messages SHOULD be sent with authentication.

   However, the node MUST NOT dynamically establish a new Security
   Association for the sole purpose of authenticating these messages.
   Automated key management is computationally intensive.  This could be
   used for a very serious denial of service attack.  It would be very
   easy to swamp a target with bogus SPIs from random IP Sources, and
   have it start up numerous useless key management sessions to
   authentically inform the putative sender.

   In the event of loss of state (such as a system crash), the node will
   need to send failure messages to all parties that attempt subsequent
   communication.  In this case, the node may have lost the key
   management technique that was used to establish the Security
   Association.

   Much better to simply let the peers know that there was a failure,
   and let them request key management as needed (at their staggered
   timeouts).  They'll remember the previous key management technique,
   and restart gracefully.  This distributes the restart burden among
   systems, and helps allow the recently failed node to manage its
   computational resources.

   In addition, these messages inform the recipient when the ICMP sender
   is under attack.  Unlike other ICMP error messages, the messages
   provide sufficient data to determine that these messages are in
   response to previously sent messages.

   Therefore, it is imperative that the recipient accept both
   authenticated and unauthenticated failure messages.  The recipient's
   log SHOULD indicate when the ICMP messages are not validated, and
   when the ICMP messages are not in response to a valid previous
   message.

   There is some concern that sending these messages may result in the
   leak of security information.  For example, an attacker might use
   these messages to test or verify potential forged keys.  However,
   this information is already available through the simple expedient of
   using Echo facilities, or waiting for a TCP 3-way handshake.

   The rate limiting mechanism also limits this form of leak, as many
   messages will not result in an error indication.  At the very least,
   this will lengthen the time factor for verifying such information. 

ref.:http://www.faqs.org/rfcs/rfc2521.html