Subject: responding to unknown SPIs

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 22 Mar 2004 11:09:15 -0800

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: Bill Sommerfeld <[email-masked]>
Date: Mon, 22 Mar 2004 15:17:32 -0500

> their context anyway in this case?  What is the scenario for which a 

when communications patterns are such that one side primarily
initiates one-way exchanges, and the responder reboots, the initiator
will keep sending with a bad SA until it times out.

on the other hand, if you can get an authenticated IPsec-level-equivalent
of a TCP RST, initiator and responder can resynchronize much more quickly.

					- Bill

---

From: "Scott G. Kelly" <[email-masked]>
Date: Mon, 22 Mar 2004 14:51:31 -0800

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