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

From: Karen Seo <[email-masked]>
Date: Tue, 30 Sep 2003 01:49:09 -0400

Folks,

Here's a description and proposed approach for:

IPsec Issue #:	84

Title:		DROP'd outbound packet

Description
===========

         Plaintext  |---------------|
         Outbound   |               |
Sender  ---------->|     IPsec     | ----> IPsec
                    |     entity    |       Peer
                    |               |
                    |---------------|

Should there be a defined ICMP response to be used when an IPsec 
implementation drops an outbound packet to indicate to the sender 
that the packet was dropped? The packet could be dropped for several 
kinds of reasons:

a. the policy mandated by the receiver's SPD entry (DISCARD)
b. inability of the initiator to set up the required SA -- There are 
many reasons why this might happen.  The IPsec peer at the other end 
of the exchange is down, is administratively prohibited from talking 
with the initiator, etc.

Just for easy reference... the IPv4 and IPv6 "destination unreachable 
types and codes are:

IPv4:

Type    Name                                     Reference
----  -------------------------                  ---------
  3    Destination Unreachable                    [RFC792]

       Codes
        0  Net Unreachable
        1  Host Unreachable
        2  Protocol Unreachable
        3  Port Unreachable
        4  Fragmentation Needed and Don't
           Fragment was Set
        5  Source Route Failed
        6  Destination Network Unknown
        7  Destination Host Unknown
        8  Source Host Isolated
        9  Communication with Destination Network
           is Administratively Prohibited
       10  Communication with Destination Host is
           Administratively Prohibited
       11  Destination Network Unreachable for
           Type of Service
       12  Destination Host Unreachable for Type
           of Service
       13  Communication Administratively         [RFC1812]
           Prohibited
       14  Host Precedence Violation              [RFC1812]
       15  Precedence cutoff in effect            [RFC1812]

IPv6:

Type  Name                                       Reference
----  -------------------------                  ---------
   1   Destination Unreachable                    [RFC2463]

       Codes
        0 - no route to destination
        1 - communication with destination
            administratively prohibited
        2 - (not assigned)
        3 - address unreachable
        4 - port unreachable

Proposed approach
=================
Add text saying something along the lines of...

"For the situation where an IPsec system receives an outbound packet 
which it finds it must drop, it SHOULD be capable of generating and 
sending an ICMP message to indicate to the sender of the outbound 
packet that the packet was dropped.  The type and code of the ICMP 
message will depend on the reason for dropping the packet.  The 
reason SHOULD be recorded in the audit log.

a. the selectors of the packet matched an SPD entry requiring the 
packet to be dropped -->

IPv4	Type = 3 (destination unreachable)
	Code = 13 (Communication Administratively
                    Prohibited)

IPv6	Type = 1 (destination unreachable)
	Code = 1 (Communication with destination
                   administratively prohibited

b1. 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 is administratively prohibited from communicating with 
the initiator and rejects the negotiation.

IPv4	Type = 3 (destination unreachable)
	Code = 13 (Communication Administratively
                    Prohibited)

IPv6	Type = 1 (destination unreachable)
	Code = 1 (Communication with destination
                   administratively prohibited

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?

IPv4	Type = 3 (destination unreachable)
	Code = ??

IPv6	Type = 1 (destination unreachable)
	Code = ??

Note that an attacker behind a security gateway could send packets 
with a spoofed source address, W.X.Y.Z, to an IPsec entity causing it 
to send ICMP messages to W.X.Y.Z.  This creates an opportunity for a 
DoS attack among hosts behind a security gateway. To address this, a 
security gateway SHOULD include a management control to allow an 
administrator to configure an IPsec implementation to send or not 
send the above ICMP message, or to rate limit the transmission of 
such ICMP responses.

Thank you,
Karen

---

From: Francis Dupont <[email-masked]>
Date: Tue, 30 Sep 2003 12:01:44 +0200

In your previous mail you wrote:

   IPv6:
   
   Type  Name                                       Reference
   
=> draft-ietf-ipngwg-icmp-v3-02.txt is more up to date.

          Codes

=> reassigned to "beyond scope of source address"

           3 - address unreachable
           4 - port unreachable

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

Regards

[email-masked]

---

From: Charles Lynn <[email-masked]>
Date: Tue, 30 Sep 2003 10:03:04 -0400 (EDT)

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