Issue #85 DROP'd inbound packet -- does not match SA

[Tero Kivinen <kivinen@ssh.fi>]

There has been some discussion about this issue and I do not think we
have reached concensus what to do with this issue. The problem is that
we do not have the original encrypted packet when we want to send the
ICMP, thus we need to re-encrypt the packet and then we end up trouble
which SA to use and what the other end will do with the packet as it
reaches it.

One possible solution to this is not to use ICMP messages at all.
Because this kind of solution can only happen when the other end is
configured incorrectly or have bugs. If the SA is manual keyed SA
there is nothing we can really do. If it is IKE negotiated SA we could
find out the IKE SA tied to the SA (in IKEv2 this is easy, for IKEv1
it is harder, and the IKE SA might not be there anymore).

If we find the IKE SA associated with the IPsec SA we could send IKE
notification to the other end saying that received packet which was
droped because of selector checks.

This is identical to the INVALID_SPI notification currently in both
IKEv1 and IKEv2. The IKE notifications have the SPI field, thus the
other end can detect which IPsec SA is misconfigured, and they are
authenticated, and in IKEv2 ack'ed.

The notifications might also require rate limit, but it is not that
important here, because nobody else than the other end can create
authenticated packet which do not match selectors (to make selectors
so that they do match requires changes to the protected part of the
packet).

The problem with this approach is that it requires new IKEv2
notification and IKEv2 draft should already be ready... We can
postpone this to separate draft as it does not need to be in the base
specification, or we can add following text to the IKEv2 draft:


        INVALID_SELECTORS                          XX

            MAY be sent in an IKE INFORMATIONAL Exchange when a node
            receives an ESP or AH packet whose selectors do not match
            those of the SA on which it was delivered (and which
            caused the packet to be dropped). The Notification Data
            contains the start of the offending packet (as in ICMP
            messages) and the SPI field of the notification is set to
            match the SPI of the IPsec SA. 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/