[IPsec] Comments about draft-ietf-ipsecme-ipsec-ha-00

[Tero Kivinen <[e-mail]>]

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.
-- 
[e-mail]