Re: responding to unknown SPIs

["Scott G. Kelly" <scott@airespace.com>]

I think what you do with invalid SPIs and/or resultant notifications 
depends on a number of factors, and must be left to implementers. Since 
such packets may represent a DoS attempt, there should be controls on 
the receiver to prevent naive handling of packets containing invalid 
SPIs. And in an ideal world, legitimate senders of such packets would 
detect black holes and adapt accordingly, but this frequently does not 
occur.

I work on a wireless gateway which must support numerous vendors' IPsec 
clients. I've seen connectivity losses that are not always detected by 
the client, and sometimes these clients keep sending blindly. Since I 
can detect under some circumstances whether the client is "okay" or not, 
I can initiate an IKE SA to this client if appropriate.

If it's the first I've seen of that client I can send an initial-contact 
message which hopefully will encourage the client to get a clue and quit 
using the old SA. On the other hand, if I've seen this client before, 
initial-contact is not appropriate, so I need an alternative, which is 
where the invalid-spi message becomes useful.

I think the best we can do from a standards perspective is provide the 
protocol pieces such that someone who wants to respond to an invalid SPI 
has the ability to do so _if they choose to_, and invalid-spi 
notification recipients have similar latitude. I think what key mgmt 
components are involved is a local implementation matter.

Scott

Henderson, Thomas R 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).