Tero Kivinen wrote:
Tamir Zegman writes:Ok, I get your point, so let me ask you another question, what is a negotiation?
> I'd like to comment that due to the symmetric nature of IKE SA's (an
> IKE peer can use the same IKE SA for both encryption and
> decryption), it seems difficult to enforce a limitation on the
> number of negotiations or the amount of data encrypted with the IKE
> SA. Since packets can get lost (especially notifications) the two
> IKE peers can get out of sync regarding the number of negotiations
> they had or the amount of data they encrypted. This can lead to a
> scenario in which one side thinks thatIn encrypted data yes, in negotiations they cannot. When we send
packet out we encrypt it only once, if that packet gets lost then we
retransmit already encrypted packet, thus we do not encrypt it again.
If any of those packets never reaches the destination, we time out the
negotiation. Timing out negotiations should quite rare, it normally
means that the network connection is broken or the other end rebooted.If the other end rebooted, then this is non issue, because it doesn't
have the ISAKMP SA up anymore, so we can remove the ISAKMP SA
immediately. If the network connection is broken, then there isn't
really anything we can do, and is is almost impossble to
distinguishing broken network connection from the reboot of the other
end (when the other end has policy that it doesn't send any
notifications back). In both cases we can just delete the ISAKMP SA
and retry creating the ISAKMP SA, to see if that helps.The negotiation lifetime counter is only incremented when IPSEC SA is
really created (thus when we create keying material for it and use
SKEYID_d for that). This means that only way we can get out of sync is
that network breaks down after second packet of the quick mode, but
before the initiator has possibility to send the final third packet.
In this case initiator has one negotiation more than the responder
has. Actually this is correct, because initiator has already consumed
entropy from the SKEYID_d when it created the IPSEC SA and the
responder hasn't done that yet.And getting out of sync isn't really a problem. It just means other
end will just delete the ISAKMP SA earlier. When we have acknoledged
deletes then this is not really a problem.