Subject: [Hipsec] responding to unknown SPIs

From: [email-masked] (Henderson, Thomas R)
Date: Thu Apr 8 11:52:01 2004

About a month ago, I queried the ipsec group about whether we should
handle unknown SPIs.  Below are a subset of the various responses, for=20
the benefit of those not on the ipsec list. =20

In summary, since we adopted a NOTIFY mechanism similar to IKEv2, I=20
think that it is appropriate to carry the INVALID_SPI notification=20
as a "MAY", like IKEv2 does.

Petri, please see proposed modified text for the base spec, and I
suggest that we can close this issue.

      INVALID_SPI                               11

         MAY be sent in a NOTIFY packet when a node receives an ESP
         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.  The NOTIFY may in this case
         be helpful for faster recovery, and possibly for debugging.
         Note, however, that sending ESP packets with invalid SPIs to=20
         a node may constitute an attack, so an implementation sending
         INVALID_SPI should adopt measures such as rate limiting the=20
         notifications or other filters. =20

Tom

(responses from ipsec list below)

> - in practice, if a reboot has occurred, won't applications have lost=20
> their context anyway in this case?  What is the scenario for which a=20
> response is useful?

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 Sommerfeld

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

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

I can initiate an IKE SA to this client if appropriate.

 - Scott Kelly

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 Kaufman

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.

  - Tero Kivinen

> -----Original Message-----
> From: Henderson, Thomas R=20
> Sent: Wednesday, March 10, 2004 3:05 PM
> To: [email-masked]; [email-masked]
> Subject: [Hipsec] responding to unknown SPIs
>=20
>=20
> (cross-posted for now to IPsec and HIP mailing lists).
>=20
> This is a request from the HIP WG for some information from IPsec WG=20
> participants.
>=20
> At last week's HIP meeting, there was some discussion on whether HIP
> (which functions similar to an IPsec key management protocol) should=20
> respond to ESP packets received with an unknown SPI. =20
>=20
> 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)
> - 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=20
> their context anyway in this case?  What is the scenario for which a=20
> response is useful?
>=20
> In looking at the latest draft (below), it seems that IKEv2 MAY
> respond, either within the SA context or outside, to these=20
> unknown SPIs, but there is not much further guidance given.
>=20
> 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?
>=20
> Thanks,
> Tom
>=20
>=20
> From http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-12.txt
>=20
>         INVALID_SPI                              11
>=20
>             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=20
> 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=20
> wrong (because
>             it could easily be forged).
>=20

---

From: [email-masked] (Tim Shepard)
Date: Thu Apr 8 13:37:00 2004

It seems to me that the question of what to do when a host has both an
IKE or IKEv2 implementation running on it, and also a HIP
implementation, should both the HIP and IKE{,v2} implementations each
send their own kind of invalid SPI notifications?

It also seems that if IKE and HIP are to coexist on the same computer,
then there will need to be some mechanism to coordinate the assignment
of SPIs.

Maybe IKE{,v2} and HIP should be implemented in the same daemon.

Maybe we should just extend IKEv2 to do what we need for HIP that
IKEv2 does not already do, and then call it IKEv2+HIP or IKEv3..

I'm just thinking out loud here.

			-Tim Shepard
			 [email-masked]

---

From: [email-masked] (Julien Laganier)
Date: Tue Apr 13 03:51:00 2004

On Thursday 08 April 2004 20:18, Tim Shepard wrote:
> It seems to me that the question of what to do when a host has both
> an IKE or IKEv2 implementation running on it, and also a HIP
> implementation, should both the HIP and IKE{,v2} implementations
> each send their own kind of invalid SPI notifications?

In case they do, it doesn't cause that much harm...

For example, one side reboot, then it receives a ESP packet with 
unknown SPI. Both HIP and IKEv2 implementations send an "invalid SPI" 
notification, and both HIP and IKEv2 running on the receiver get 
them:

o If this was a HIP-related ESP packet, the IKEv2 implementation 
wouldn't know anything about this SPI, hence should discard the 
notification, while the HIP implementation would have an associated 
state and answer conveniently.

o If this was a IKEv2-related ESP packet, the reverse apply as well.

> It also seems that if IKE and HIP are to coexist on the same
> computer, then there will need to be some mechanism to coordinate
> the assignment of SPIs.

The mechanisms is already implemented in all the IPsec stacks I know 
about (*BSD/KAME, Linux and Solaris), through the use of the PFKEY_V2 
API. A key management daemon should first send to the IPsec stack an 
SADB_GETSPI, in order to allocate an SA and a free SPI, and then use 
SADB_UPDATE to fill-in others SA parameters (peers, alg, keys).

> IKEv2 does not already do, and then call it IKEv2+HIP or IKEv3..

Indeed, this can be an interesting option... IKEv2 is 2 round trips 
long for ESP/AH SA creation so it compares quite well with HIP. But 
anyway, HIP over IKEv2 need some extensions (at least for Rendez-Vous 
Server) that we do need to speficy to really know if this is 
possible.

Also, this sounds like a bit of regression because it means that we 
need to throw away some of the specification and implementation work 
that already happened. BTW I dunno if there's running implemenation 
of IKEv2... anybody?

--julien

---

From: [email-masked] (Petri Jokela)
Date: Tue Apr 13 06:52:01 2004

Henderson, Thomas R wrote:
  > In summary, since we adopted a NOTIFY mechanism similar to IKEv2, I
> think that it is appropriate to carry the INVALID_SPI notification 
>          Note, however, that sending ESP packets with invalid SPIs to 
>          INVALID_SPI should adopt measures such as rate limiting the 
>          notifications or other filters.  

Thanks Tom!

So, we shall remove all current definitions and mechanisms how to 
respond to unknown SPIs and define that the response MAY be a NOTIFY 
packet with an INVALID_SPI. How to react to an incoming INVALID_SPI 
would depend fully on the implementation and no rules shall be defined 
for it.

There were some issues bundled together, namely issues 12, 15, 19, 20 
and 22.

The issue 12, birthday check badly defined, was subject of removal if 
the resync would have been removed from the draft. Now, the new COOKIE 
(issue 33) would contain the birthday in any case, so this issue is now 
related to this issue 33 and not yet closed.

The issue 15, the possible removal of birthday count, is not valid after 
the introduction of the new COOKIE with birthday. Thus I suggest that 
this issue will be closed.

The issue 19, RESYNC bit in I1, is now resolved by introducing the 
UNKNOWN_SPI in the NOTIFY packet. So, this issue could be closed.

The issue 20, I1 and R1 packet definition bug, can be closed if we 
remove all the defined actions for responding to unknown SPIs with I1/R1 
packets.

The issue 22, Remove RESYNC mechanism from the draft, would be closed as 
proposed by Tom.

/petri

-- 
Petri Jokela                        Tel:    +358 9 299 2413
Research scientist                  Fax:    +358 9 299 3535
NomadicLab, Ericsson Research       Mobile: +358 44 299 2413
Oy L M Ericsson Ab                  email: [email-masked]

---

From: [email-masked] (Miika Komu)
Date: Tue Apr 13 06:55:01 2004

> Maybe IKE{,v2} and HIP should be implemented in the same daemon.

This would be quite interesting because our HIP implementation does not
have any userspace daemon ;) It runs entirely in the kernelspace.

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/