Subject: Re: 2401bis Issue # 85 -- DROP'd inbound packet -- does not match SA

From: "Joseph J. Tardo" <[email-masked]>
Date: Tue, 30 Sep 2003 21:11:01 -0700

This ICMP message MUST be sent encrypted using the reverse direction SA (or
similar appropriate terminology) and MUST NOT be sent in the clear.

At 01:49 AM 9/30/03 -0400, Karen Seo wrote:
>Folks,
>
>Here's a description and proposed approach for:
>
>IPsec Issue #:	85
>
>Title:		DROP'd inbound packet -- does not match SA
>
>Description
>===========
>Should there be a defined ICMP response to be used when an IPsec 
>implementation  drops an inbound, IPsec-protected packet, whose 
>selectors do not match those of the SA on which it was delivered? 
>The intent is to indicate to the sender that the receiver dropped the 
>packet.
>
>Proposed approach
>=================
>Add text saying something along the lines of...
>
>"If an IPsec system receives an inbound packet whose selectors do not 
>match those of the SA on which it was delivered, it MUST drop the 
>packet.  It SHOULD also be capable of generating and sending an ICMP 
>message to indicate to the sender (the IPsec encapsulator) that the 
>packet has been dropped by the receiver.  The reason SHOULD be 
>recorded in the audit log.
>
>IPv4	Type = 3 (destination unreachable)
>	Code = 13 (Communication Administratively
>                    Prohibited)
>
>IPv6	Type = 1 (destination unreachable)
>	Code = 1 (Communication with destination
>                   administratively prohibited
>
>"The implementation SHOULD provide management controls 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: Markku Savela <[email-masked]>
Date: Wed, 1 Oct 2003 11:06:08 +0300

> From: "Joseph J. Tardo" <[email-masked]>
> 

Using what encryption?

  a) you have policy selector entry for this ICMP message? Doubtfully
  working, as other end is already shown to be badly out of synch in
  respect to policies..

  b) use the selectors extracted from the returned packet (instead of
  the outer Error ICMP) to choose the policy and IPSEC for the ICMP
  message.

  c) use the incoming SA's to find suitable matching outgoing SA's and
  use them (doubtful, as such they may not exist, and this would
  bypass the SPD, and could expose some security problems).

I consider the (b) to be the "right" way to do it in general for ICMP
error messages, but in this case again, it's unlikely that other end
would accept it (because it already has shown to be using incorrect
policy).

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 1 Oct 2003 12:46:29 +0300

> > similar appropriate terminology) and MUST NOT be sent in the clear.

Same level, that was used when the packet came in. There is no other
choise. The original packet is included in the ICMP message, thus
sending it in clear or with lower security level would be security
problem. 

>   bypass the SPD, and could expose some security problems).

Actually any of those would propably be ok, but preferred order would
be c, b, and then a.

In c this would mean that find the other direction pair of the
incoming SA and use it, thus the packet would get exactly same
protection when sent back. If the other end drops it then there is
nothing we can do for it...

The b is otherwise fine, but it might be that we do not have policy
for the return traffic at all (i.e we have policy from port 80 to port
8080 from vpn-client to sgw, but we do not allow traffic from sgw to
the vpn-client port 80). This would mean that we do not find the
policy for the internal packet, we find the policy for the packet that
would be reply for the internal packet. This might not be so easy.

In a case there is problem that the ICMP messages might have quite
different security configuration compared to the original traffic. I.e
it might even have configuration saying send all ICMP messages in
clear, and protect all UDP traffic from remote port 514 (syslog) to
local port 514 at host 10.0.0.1 (syslog.company.com) with 3DES. The
security policy tries to protect all logging going to 10.0.0.1 from
the vpn-client with 3DES.

Now if the client has configuration error in syslog.conf and it sends
packets to 10.0.0.2 instead of 10.0.0.1, then the sgw would decrypt
those packets, notice that they do not fit the selectors, and send
ICMP error containing the original logging packet in clear.

There might even be protocols where the packets contains plain text
passwords, which are supposed to be protected by ipsec...

One, option that would get rid of all of this discussion, would be to
say that ICMP error message contains the original encrypted packet,
not the decrypted packet. I.e when encrypted packets come in, it is
stored, decrypted, and then selectors are checked. If the selectors
does not match, then original stored packet is retrieved, and clear
text ICMP error message is replied with encrypted packet inside.

Of course in that case the responder might have problem to actually
find out why it didn't fit the selectors, as it needs to dig the
original packet out, decrypt it using the keys only in the encryption
SA, only then it can see the selectors....

> would accept it (because it already has shown to be using incorrect

I would say the c is the easiest and best way. If you are using IKE
then you will have SAs in pairs, thus you can find the matching SA
pair for the incoming SA, and use that. If you are using manual keying
or SA in other direction has already expired, or you do not maintain
the SA pair information, then you cannot send ICMP error messages
back.

> > >Title:		DROP'd inbound packet -- does not match SA

Actually we could say that the rate limit is given in number of ICMP
messages per minute, and value 0 means do not ever send ICMP error
messages :-)
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/