Subject: RE: responding to unknown SPIs

From: "Charlie Kaufman" <[email-masked]>
Date: Wed, 24 Mar 2004 13:36:13 -0800

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

---

From: "Bora Akyol" <[email-masked]>
Date: Wed, 24 Mar 2004 17:32:40 -0800

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Charlie Kaufman
> Sent: Wednesday, March 24, 2004 1:36 PM
> To: Henderson, Thomas R; [email-masked]
> 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.
> 
> -----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.
> 
> - 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 looking at the latest draft (below), it seems that IKEv2 
> MAY respond, either within the SA context or outside, to these 
> 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: Tero Kivinen <[email-masked]>
Date: Thu, 25 Mar 2004 16:03:36 +0200

> however because the other side thinks that the SAs are not up.

No you cannot in IKEv2. 

> 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 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. 
-- 
[email-masked]