Keepalives (was RE: responding to unknown SPIs)

["Bora Akyol" <bora@cisco.com>]

Charlie

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.

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.

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.

Thanks

Bora



> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com 
> [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Charlie Kaufman
> Sent: Wednesday, March 24, 2004 1:36 PM
> To: Henderson, Thomas R; ipsec@lists.tislabs.com
> Subject: RE: responding to unknown SPIs
> 
> 
> I can't speak for the implementation experience around 
> 'unknown SPI' notifications, but can explain the logic behind 
> what's in the IKEv2 spec.
> 
> IKEv2 defines a syntax for an INVALID_SPI notification, but 
> does not require that they ever be sent and says that they 
> MAY be ignored by recipients. It warns against sending them 
> frequently enough to become an amplifier of a DOS attack or 
> using them as definitive indications that they other end has rebooted.
> 
> IKEv2 tests liveness with keep alive messages (which can be 
> skipped if there is other traffic on the SA). This mechanism 
> is reliable without INVALID_SPI notifications. There are two 
> reasons INVALID_SPI might be useful. One is to trigger a 
> liveness check and hence speed up recognition that a node has 
> rebooted. The other is as a debugging aid trying to figure 
> out what's going on if the network and/or one of the 
> endpoints is flakey.
> 
> I would expect most implementations to not bother with them.
> 
> 	--Charlie
> 
> -----On Monday, March 22, 2004 11:09 AM, Thomas R Henderson 
> wrote: This is a request from the HIP WG for some information 
> from IPsec WG 
> participants.
> 
> At IETF-59, there was some discussion on whether HIP (which functions 
> similar to an IPsec key management protocol) should respond to ESP 
> packets received with an unknown SPI.  
> 
> Some issues raised included:
> - don't IPsec key management protocols ignore these? (It was 
> pointed out by a participant that the latest draft of IKEv2 
> has support for responding to them, in the Notify Payload)
> - what if multiple keying daemons (HIP, IPsec) are running on 
> the same box-- do both respond?
> - what is the appropriate response, if there is one?  
> (inside/outside SA context, rate limited, request to 
> reestablish the SA?)
> - is a response dependent on whether the localhost determines 
> that it has rebooted recently?
> - in practice, if a reboot has occurred, won't applications have lost 
> their context anyway in this case?  What is the scenario for which a 
> response is useful?
> 
> In looking at the latest draft (below), it seems that IKEv2 
> MAY respond, either within the SA context or outside, to these 
> unknown SPIs, but there is not much further guidance given.
> 
> In summary, at the HIP WG it was not clear if this was a 
> useful mechanism, so we decided to defer to IPsec WG for 
> guidance.  Has it been found to be useful?
> 
> Thanks,
> Tom
> 
> 
> From http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-12.txt
> 
>         INVALID_SPI                              11
> 
>             MAY be sent in an IKE INFORMATIONAL Exchange when a node
>             receives an ESP or AH packet with an invalid SPI. The
>             Notification Data contains the SPI of the invalid packet.
>             This usually indicates a node has rebooted and 
> forgotten an
>             SA.  If this Informational Message is sent outside the
>             context of an IKE_SA, it should only be used by the
>             recipient as a "hint" that something might be 
> wrong (because
>             it could easily be forged).
>