Subject: [Ipsec] Simultaneous initial keying on an IPsec SA in IKEv1

From: "James Comen (NC/TNT)" <[email-masked]>
Date: Mon, 19 Sep 2005 09:14:15 -0500

I have seen discussions addressing simultaneous RE-keying of IPsec SAs in IKEv1.  The issue can be addressed by adjusting the rekey timeout based on whether a peer is initiator or responder.

However, I have not seen simultaneous keying addressed as part of the initial keying.  In a normal situation this should not occur. In a normal situation, one side attempts to send a packet which requires IPsec protection.  Based on that, normal keying occurs.

Consider a testing scenario in which a traffic generator is connected to either peer (and the peers are connected directly or indirectly).  When the traffic generator starts, it sends packets to both peers (destined for the 'other' peer) causing each peer to attempt to create IKE/IPsec SAs.  In this case, each peer is acting as both initiator and responder.  

Given this, I assume the best that could happen would be duplicate SAs.

I assume the worst that could happen woud be the following:
Each peer, acting as initiator, allocates an SPI value for the for the incoming SA and then initiates a P2 exchange.  Each P2 exchange stalls later when each peer receives the first p2 message and, then, acting as responder, tries to allocate an incoming SPI. It will fail because a SPI value has already been allocated for the incoming SA.

Is this a problem?
Has it been addressed or is it local to my implementation?

Thanks,
Jim
_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: [email-masked]
Date: Mon, 19 Sep 2005 17:46:37 +0300

James Comen (NC/TNT) wrote:

> Each peer, acting as initiator, allocates an SPI value for the for
> the incoming SA and then initiates a P2 exchange.  Each P2 exchange
> stalls later when each peer receives the first p2 message and, then,
> acting as responder, tries to allocate an incoming SPI. It will fail
> because a SPI value has already been allocated for the incoming SA.

Why would allocating an incoming SPI fail in this case? 

(Or does your implementation support only a single incoming IPsec SA?
But then it probably wouldn't be compliant with 2401bis...)

Best regards,
Pasi