Re: issue 11 -- window size

Jari Arkko writes:
> OK, I see the problem now. It looks like there are
> sevaral subtasks in what we are trying to do:
> 
>   (i) test
>  (ii) commit to particular set of addresses
> (iii) manage unidirectional connectivity (#19)
> 
> Tero's model, as I understand it, appears to combine
> both (i) and (ii) as well as disallow unidirectional
> connectivity. In a sense his model is less flexible, but
> at the same time simpler. A good tradeoff? Lets think
> about it.

The protocol in my model can be defined either to combine (i) and (ii)
or do them as separate steps. i think it might be better to do them
in separate steps.

On the other hand in my proposal all (ii) commit messages are also
always (i) test messages too, but not other way around.

(iii) I do not think we should try to work around with unidirectional
connectivity. 

> Anyway, presumably you could modify Tero's proposal
> to separate (i) and (ii). The drawback in that is that
> if there's a change in connectivity between initiating
> (ii) and completing it, you have no possibility to send a
> test message -- only a commit message. This is because
> the model requires sequenced delivery of all messages.

But as each (ii) is also (i) message, the result of that will be that
you have done new test and have a new address pair that works, so you
can initiate (ii) again immediately and move traffic there. In the
mean time the traffic might be going to some other non-working
address, but that it was most likely going to non-working address
already before, as that is the reason why we started (ii), so no
difference there.

> But what exactly is the problem that results from this?
> Presumably you wanted to commit to a particular
> set of addresses. So the only reason why you might
> want to start testing is that you don't get a response.
> If you have just one alternative left, then there's no
> issue -- switch to it, with commit, if you can. But if there
> are multiple alternatives, then you might wish to test
> which one to choose.

In my proposal you can test it with empty information exchange (i.e.
DPD). That will return new working pair of address. I had separate
N(MOVE TRAFFIC) notify which was used to move traffic. But as N(MOVE
TRAFFIC) is normal IKEv2 packet then it also acts as test packet.

> Question: could you do this by ordering the retransmissions of the
> commit message in a proper way? (Or am I now in the area of trying
> to fix the special cases that you Pasi were worried about?)

The protocol could periodicly or every time it notices change do path
test with all paths with normal DPD style packet. That would not do
any change in the MOBIKE state yet. When the working best path is
found then the protocol could move traffic to new address pair by
N(MOVE TRAFFIC) notify.

For IKEv2 NAT-T interaction you have also couple of options. Easiest
is simply say that NAT-T works as defined in the IKEv2, but the SHOULD
for implicit update is MUST, and if initiator detects that N(MOVE
TRAFFIC) did't go through with selected pair, and it needs to rever to
test path method, then it needs to do N(MOVE TRAFFIC) again with new
working path.
-- 
[email protected]