[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Keepalives (was RE: responding to unknown SPIs)



Bora Akyol writes:
> Sending the keepalive messages on the IKE SA itself is not
> enough to conclude that the data connection is alive. Unless
> IKE v2 mandates keepalives to be sent in the data connection
> as opposed to the control connection, this does not solve
> the problem.
> 
> You can have an IKE SA up, one side can think IPSEC SAs are up,
> however because the other side thinks that the SAs are not up.

No you cannot in IKEv2. 

> At least with IKE v1, this situation arises when the last message
> of an exchange gets lost. I am afraid a similar circumstance can
> happen in IKE v2 but I have not verified this in the lab so
> I am not going to say it does.

The initiator is mandated to resend the final packet until it gets
reply back to that. If it does not get reply ever, it will assume that
the IKE SA has failed, and tear down the IKE SA along with all IPsec
SAs created with that IKE SA. So if that happens then the other end
will remove both IKE and IPsec SAs, and the next keepalive packet will
fail and the other end will also do the same.

Also the IKEv2 drafts forbids conditions where the IPsec SA could fail
when the IKEv2 SA still works. I.e. if the IPsec SA processing is
offloaded to another processor, and that processor can fail separately
from the IKE SA processor, then IKE SA processor must make sure that
the IPsec SA processor is alive and working all the time. If the IPsec
SA processor fails (or loses SAs), then IKE SA processor must remove
IKE SAs too.

> And under these conditions, the keepalives on the IKE SA 
> are not useful at all. You do need the INVALID_SPI message.
> However, I think this message itself is a DOS attack magnet for
> a security gateway so I would rather not implement it at all,
> and solve the lost message problem in a different way.

The INVALID_SPI message is used when your host is just rebooted, and
you receive ESP packet which has unknown SPI. You could simply ignore
it, and after couple of minutes or tens of minutes (depending on the
configuration) the other end will notice that you are not responding
to its IKE keepalives, and tear down the IKE and IPsec SAs.

If instead of that you send unprotected INVALID_SPI notification, then
the other end will immediately know that there might be problem, thus
it can immediately send keepalive, and when you do not reply that
within say 60 seconds (after 3-10 retransmits or so), then it can tear
down the IKE SA and IPsec SA. After that the next packet will trigger
the creation of the new IKE and IPsec SA and the connection is up and
running again.

You do not want to send protected INVALID_SPI as that would require
you to first create IKE SA besed on completely unauthenticated ESP
packet having invalid SPI. 
-- 
kivinen@safenet-inc.com