RE: issue 11 -- window size

[email protected] writes:
> - Current path (A1,B1) stops working, and the peers switch 
>   to (A2,B2). A is behind a NAT in both cases.
> 
> - After a while (A2,B2) still works (and continues working), but
>   the peers really prefer (A1,B1) because it's faster/cheaper/
>   whatever. So, A sends the last request using addresses (A1,B1) 
>   to see if it has become operational again.
> 
> - Suppose that direction A1->B1 works, but B1->A1 does not
>   (e.g. because of a malfunctioning middlebox or something; the
>   cause does not really matter). B receives the packet, and if
>   it hasn't seen it yet, processes it, sends reply, and (if it
>   implements the NAT-T "SHOULD" from IKEv2) moves all traffic to 
>   path (A1,B1). Which does not work.

Yes, IKEv2 NAT-T does not support unidirectional paths. That does not
mean that our MOBIKE protocol needs to do that.

On the other hand, I am not sure we want to support unidirectional
paths. I had a feeling we already somewhere decided that we do require
two-way connection between working addresses, i.e. we are not supposed
to support such thing.

The MOBIKE protocol can simply use path test and actual changes as a
separate message, there is no reason to do the changes based on the
other packets. On the other hand other packets can be used as a path
test message, as it does answer to the question "does this path
work?"

> - In MOPO-IKE, path test is a separate message primarily
>   because then it cannot interfere with anything else. Here, 
>   host A would not receive B's reply to the PATH_TEST 
>   message, and traffic would stay on path (A2,B2) which 
>   is working fine.

If MOBIKE protocol uses separate N(MOVE TRAFFIC) then that thing can
only happen for very short time, and it will be fixed immediately
after that.

I.e. if we detect that A1<->B1 path works in both ways and we want to
move to it, and we send N(MOVE TRAFFIC). If the path A1<->B1 now
breaks so that A cannot get reply back, but B has already moved
traffic, then A will notice that it cannot get replies back so it
starts trying other addresses, and when it finds a working path the
traffic is then moved to that (either implicitly by B updating the
IPsec SAs for each address A tries, or explicitly by B ignoring
retransmissions of N(MOVE TRAFFIC) with different address, and A
noticing after exchange, that traffic got moved to wrong address, and
redoing the N(MOVE TRAFFIC)).

Same thing can happen in MOPO-IKE if the path happens to break between
path test and traffic move operations. 

> Of course, there are several ways how this particular problem
> could be fixed. (Or we could define this as a feature rather
> than a problem :-)

Yes, and as we are not talking about the actual protocol, we simply
need to agree here that those things can be solved. We are trying to
decide the higher level option, and if you find some fundamental
problem, which cannot be solved at all then we want to hear it now... 

> IMHO going through all these special cases and ensuring that
> they're handled correctly is more work (and more complexity in
> the spec) than a separate path test message. But perhaps the
> difference in complexity is not that big, so if people are
> really interested in working on those special cases, we could
> go that route, too...

Most of the same special cases needs to be handled regardless weather
the path test is separate or not. We need to solve the thing what to
do for the ongoing exchange when the path breaks during it. We cannot
modify the packet anymore, and we must deliver it to the end, meaning
that we need to modify the outer header of that packet anyway, thus
same problems.

I haven't read the MOPO draft for a while, so I do not remember how
those issues were solved there. Perhaps I need to reread it now and
see how things are done there... 
-- 
[email protected]