RE: issue 11 -- window size

Stephane Beaulieu writes:
> So, if you have two peers
> 
> PeerA(A1,A2) PeerB(B1,B2) which are using A1<->B1 for the initial
> connection.
> 
> Given the following sequence of events
> - Window Size = 1
> 
> A1 --> B1 (CREATE_CHILD_SA request)
> Interface A1 goes down
> A1 x-- B1 (CREATE_CHILD_SA response)
> 
> How would PeerA inform PeerB to start using A2?  It is unable to send any
> IKE pkts at all without exceeding the window size.  Or are you relying on
> PeerB to retransmit the response to A1 a few times, and then automatically
> switch to A2?

As only party doing retranmissions in the IKE is the initiator, the
PeerA would continue retransmitting the CREATE_CHILD_SA to the PeerB
as long as it does not get reply back.

After a while after it haven't received reply (or immediately when it
detects that A1 goes down) initiator (peerA) should start path
finding, i.e it should send next retranmission of packet:

A2 --> B1 (CREATE_CHILD_SA request)

PeerB would retransmit its reply to new IP-address

A2 <-- B1 (CREATE_CHILD_SA response)

And they have now finished the exchange, and continue processing. Now
next thing what PeerA would like to do, is probably update his
addresses to the PeerB, if A1 really went away, or at least move
existing IPsec SA traffic to use address pair of A2, B1 which is known
to work now (this update could also be automatic).

There are some other options how this protocol could be written, but
this is just one example how the protocol could be written (i.e.
mostly to give proof that we do not necessarely need PATH_TEST
exchange which is outside the window, or we do not necessarely need
window size > 1).
-- 
[email protected]