Re: 2401bis Issue # 84 -- DROP'd outbound packet

[Charles Lynn <clynn@bbn.com>]

Francis observes:

> => IMHO the code should follow the reason why the IPsec peer could not
> be contacted with code 1 by default?

To amplify, it is hard for the receiver of an ICMP message that only
uses one code to decide how to respond/notify the user about the
detected error.  There are several cases:

1) There are (temporary) network connectivity problems during IKE; the
   communication should be retried "in a while".

2) There are (temporary) (black or red)	network connectivity problems
   during the user's communication, the communication may not succeed
   at the current time; one could wait, or try again later.

3) The communication is prohibited by policy; do not retry until the
   security officer(s) have reached an agreement.  Note that the
   prohibition can be detected by either of the IKE peers.

4) The packet that was received is protected as required by the local
   policy, but it is not a packet that should be sent via the SA that
   was used (access control violation); your implementation is broken,
   or your key has been compromised.  The SG transiting the ICMP might
   try to rekey the SA to establish a new key, but that will not fix a
   broken implementation.

5) The packet that was received is not protected as required by the
   local policy; this could be part of a DDoS attack, so a way to
   limit the ICMP rate is especially important in this case.

It would be nice it the user could be given some indication of the
problem so that they could initiate corrective action.

Should we define additional ICMP codes to distinguish the cases?
I think we should.