I was quickly browsing this document and here is some quick comments to it:
In section 3.2 it is only talking about counters, but for IKE SA the other MUST also be able to retransmit previous message in case it was lost. So it is not enough to transmit only the Message-ID counters (inbound window and outbound message), but also the actual packets associated with each message ID (for outbound case). If devices have window larger than one, then the outbound request window could be large, so several packets per IKE SA needs to be kept. Request packets can be forgotten when reply is received, but replies cannot be forgotten as there is no way to know whether other end received the reply or not. Good thing is that the outbound messages are static after they are sent, thus they only need to be transmitted over the synch channel once. Also in case MOBIKE is used, that will add even more state to the SAs, as the active peer addresses needs to be stored. Most likely there is no need to store the mobike process data itself, as the mobike process that was just ongoing when failure happened, can be rerun after failover. In section 3.4 there is text saying: > o It requires multiple parallel SAs, which the peer has no use for. > Section 2.8 or [RFC4306] specifically allows this, but some > implementation might have a policy against long term maintenance > of redundant SAs. This is not only allowed, it is MUST feature of RFC4301 (section 4.1 says: To permit this, the IPsec implementation MUST permit establishment and maintenance of multiple SAs between a given sender and receiver, with the same selectors. Distribution of traffic among these So even when RFC4306 says it is allowed, it is mandatory feature in IPsec architecture, thus I do not think it really matters if some implementations decide to make policy rules against it as they surely will have way to turn those policy rules off to be able to be RFC4301 complient. Also I think the other two "shortcomings" are not really relevenat here. The firewall or deep inspection engine actiong on the load balancing devices, must be able to cope with the problem anyways. Also IPsec does not have return packets, thus where those imaginary return packets come in does not matter. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
