issue 11 -- window size

Jari Arkko writes:
> 
> This issue is about the window size. Mobike needs to be able to
> send multiple messages, given that a regular IKEv2 exchange
> may be in progress when we suddenly change our IP address.
> The question is whether we should expect IKEv2 implementations
> to support window size greater than 1, or if Mobike's own
> exchanges are in some sense outside the regular IKEv2
> window (as proposed in Pasi's MOPO protocol).
> 
> The background information we got in the meeting was that
> in the IKEv2 bakeoff many implementors did not have
> support for larger than 1 window sizes.
> 
> So we could either require a larger window size or do MOBIKE
> exchanges outside the window. I did not sense a conclusion
> in the meeting about this, but on the other hand I'm not sure
> if people care about this issue very deeply. For the purpose
> of making progress, let me propose one approach. If the
> decision was "do it outside the window", would people have
> problems with that?

There is also one other option, i.e. the way my original protocol
proposal did it, i.e. every IKE packet can be used to test the paths.
If you add also so that every IKE packet also includes the information
needed to do mobility that solves the problem with window size 1.

I.e. if mobike needs n payload for its processing, you add those n
payloads to all IKE packets, and then when you are retransmitting the
IKE packet you simply also use that packet to do path finding, i.e.
change the source and destination addresses but keep the packet same.
The responder will reply to reversed addresses, and after that IKE
exchange both ends know that the path has changed, and can take
appropriate actions (either automatically or manually by sending
another exchange).

That protocol will work with window size of 1, and it does not need
any packets that are outside of the normal window processing. If we
still do manual actions, then we actually do not need any special
payloads in the IKE packets.
-- 
[email protected]