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

From: Francis Dupont <[email-masked]>
Date: Wed, 01 Oct 2003 16:40:25 +0200

In your previous mail you wrote:

   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".
   
=> if the source of the problem is known so the code to use is known,
if it is not known, code 1 is a good default.

   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.
   
=> same.

   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.
   
=> code 1

   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.
   
=> code 1

   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.
   
=> code 1 (and I agree about the rate limit)

   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.

=> if you believe we need new things, IMHO it should be a new type and
not new codes. And it should be easier to get...

Regards

[email-masked]

PS: code 1 is "communication with destination administratively prohibited".

---

From: Karen Seo <[email-masked]>
Date: Wed, 15 Oct 2003 00:08:47 -0400

Folks,

	Thank you for the suggestions re: which code to use for the
	following case....

>b2. the IPsec system was unable to set up the SA required by the SPD 
>entry matching the packet because the IPsec peer at the other end of 
>the exchange could not be contacted.  The type should be destination 
>unreachable, but what codes should we use?

	While it would be desirable for the sender to be notified
	of the true cause of the failure to set up the needed SA,
	given that the IPsec system may not be able to verify the
	ICMP info it receives about the cause of the set up failure,
	how about if we use:

		IPv4	Type = 3 (destination unreachable)
			Code = 1 (host unreachable)

		IPv6	Type = 1 (destination unreachable)
			Code = 3 (address unreachable)

	This would let us avoid the effort and time to needed to
	define and obtain additional types and codes.

Thanks again,
Karen