So I noticed that ever since switching to ipsec-tools racoon, I get a bunch of 
these in syslog:

Mar 12 20:38:45 hiroshima racoon: INFO: ISAKMP-SA expired 10.3.0.4
[500]-10.3.0.1[500] spi:eca1bc05ae30df69:baaaaf4e19740f44
Mar 12 20:38:45 hiroshima racoon: INFO: ISAKMP-SA expired 10.3.0.4
[500]-10.3.0.1[500] spi:bc95329608c082a1:ba24c47e68eb9ffb
Mar 12 20:38:45 hiroshima racoon: INFO: ISAKMP-SA expired 10.3.0.4
[500]-10.3.0.1[500] spi:d67d78355c6951db:8a585bb8377eed8d
Mar 12 20:38:46 hiroshima racoon: INFO: ISAKMP-SA expired 10.3.0.4
[500]-10.3.0.1[500] spi:eca1bc05ae30df69:baaaaf4e19740f44
Mar 12 20:38:46 hiroshima racoon: INFO: ISAKMP-SA expired 10.3.0.4
[500]-10.3.0.1[500] spi:bc95329608c082a1:ba24c47e68eb9ffb
Mar 12 20:38:46 hiroshima racoon: INFO: ISAKMP-SA expired 10.3.0.4
[500]-10.3.0.1[500] spi:d67d78355c6951db:8a585bb8377eed8d
Mar 12 20:38:47 hiroshima racoon: INFO: ISAKMP-SA expired 10.3.0.4
[500]-10.3.0.1[500] spi:eca1bc05ae30df69:baaaaf4e19740f44
...

In fact, once an ISAKMP session expires, I get one of these messages per 
second for that session, until I restart racoon.

Upon looking at the code, I found:

1) The ISAKMP-SA ("phase 1") is only cleaned up when all of the IPsec-SAs 
("phase 2s") for it have been deleted.  Until then, it retries once a second.  
This is algorithmically poor -- it should schedule the ISAKMP-SA deletion 
when the last IPsec-SA is deleted.

2) When an IPsec-SA expires, it reinitializes the IPsec-SA structure and 
attempts to start a new negotiation.  For some reason, this sticks around, 
and leaves at least one active IPsec-SA attached to the ISAKMP-SA, causing 
neither to be GCed.  Clearly something is wrong here.

3) Meanwhile, the kernel queues a new request for an IPsec-SA, and a new 
ISAKMP-SA and IPsec-SA are negotiated.

Could someone look into these problems?  AFAICT, the ipsec-tools racoon is 
actually more broken than the KAME version.