A while back I reported that I sometimes saw double and triple SAs being created. The patch to check for protocol when deleting larval SA removed one obstacle in that I no longer see triple SAs. Now, once in a while double SAs. I think I have figured out the second obstacle.
The initiator installs his SAs into the kernel before the responder. As soon as they are installed, the blocked packet (which started the ACQUIRE) is sent. By this time the responder has installed his inbound SA(s) and so the newly arrived ipsec packet can be processed. In the case of tcp connections and a ping, a response may be warranted, and thus an outgoing packet results. >From what I can tell of the log file below, sometimes, this might happen before the responder has completed installing the outbound SAs. In the log file, the outbound AH has been added, but not the outbound ESP, which is the one the outgoing packet looks for first. Thus resulting in a second acquire. I think this becomes more problematic when using both AH AND ESP, rather than just using ESP with authentication. With the latter, only one SA needed thus reducing the latency in installing the SAs before incoming packet arrives. So far, the only solution I can think of besides mandating all userspace key daemons do SA maintenance is to perhaps add larval SAs for both directions when adding the SPI. Currently, responder does GETSPI for one way and initiator for opposite. When GETSPI is called, larval SA is created containing the SPI, but it is only for one direction. Perhaps we can add a larval SA (no SPI) for opposite direction to act as a placeholder indicating ACQUIRE occurring, since SAs are created for both directions during an ACQUIRE. The initiator may have larval SA from GETSPI and larval SA from the ACQUIRE depending that GETSPI is in opposite direction of ACQUIRE. Calling __find_acq_core() should ensure we don't create duplicate larval SAs. Also, should IKE negotiations return error, larval SAs should expire. They also should be removed when we do the xfrm_state_add() and xfrm_state_update() to add the new SAs. If this is not a good idea or there is a better way to do this, please let me know. I wanted to ask before coding and testing in case there is a better solution and I won't have wasted time. Regards, Joy mylogfile (it has been cut and pasted, so irrelevant sections left out) 2007-03-20 13:39:04: DEBUG: pfkey UPDATE succeeded: AH/Transport x.x.x.210[0]->x.x.x.55[0] spi=203125341(0xc1b725d) 2007-03-20 13:39:04: INFO: IPsec-SA established: AH/Transport x.x.x.210[0]->x.x.x.55[0] spi=203125341(0xc1b725d) 2007-03-20 13:39:04: DEBUG: pfkey UPDATE succeeded: ESP/Transport x.x.x.210[0]->x.x.x.55[0] spi=157349023(0x960f49f) 2007-03-20 13:39:04: INFO: IPsec-SA established: ESP/Transport x.x.x.210[0]->x.x.x.55[0] spi=157349023(0x960f49f) 2007-03-20 13:39:04: DEBUG: === 2007-03-20 13:39:04: DEBUG: get pfkey ADD message 2007-03-20 13:39:04: INFO: IPsec-SA established: AH/Transport x.x.x.55[0]->x.x.x.x.210[0] spi=196161037(0xbb12e0d) 2007-03-20 13:39:04: DEBUG: === 2007-03-20 13:39:04: DEBUG: get pfkey ACQUIRE message 2007-03-20 13:39:04: DEBUG: call pfkey_send_getspi 2007-03-20 13:39:04: DEBUG: pfkey GETSPI sent: AH/Transport x.x.x.210[0]->x.x.x.55[0] 2007-03-20 13:39:04: DEBUG: call pfkey_send_getspi 2007-03-20 13:39:04: DEBUG: pfkey GETSPI sent: ESP/Transport x.x.x.210[0]->x.x.x.55[0] 2007-03-20 13:39:04: DEBUG: pfkey getspi sent. 2007-03-20 13:39:04: DEBUG: get pfkey ADD message 2007-03-20 13:39:04: INFO: IPsec-SA established: ESP/Transport x.x.x.55[0]->x.x.x.210[0] spi=241180149(0xe601df5) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
