RE: issue 11 -- window size

[email protected] writes:
> Yes, I also think we should not support unidirectional paths,
> but there are two quite different ways we can do that:
> 
> 1) treat unidirectional paths the same way as totally 
>    dead paths: don't use them
> 2) assume that unidirectional paths never occur, and 
>    possibly fail in weird ways if they do
> 
> IMHO we should do the first.

I agree in that. My proposal works fine even if there is
unidirectional path, it will not simply use them. During the path test
it might try to use them, but after the path test is finished it
either has found working bi-directional path or the connection has
been broken down. 

> > 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?"
> 
> Not unless we change NAT-T a bit, because currently it can treat 
> any authenticated packet as a change (rather than just test). 
> MOPO-IKE's approach, using a separate PATH_TEST message that is
> neither part of any IKE_SA nor authenticated solves works with 
> current NAT-T behavior.

There is no need to change NAT-T unless we want to.

The initiator can detect the situation and it can fix it by sending
one more packet with proper source and destination address. The IKEv2
does not clarify if retransmissions of the previous packets are
considered as valid authenticated packets, and if the IP-addresses
needs to be updated for each of those, or only for the first.

Regardless what implementations do on that, we can simply fix the
situation by sending new N(MOVE TRAFFIC) exchange with proper address
pair.

Exactly same thing happens if the path happens to break when MOPO-IKE
is sending the address update packet, and path happens to break in the
middle of that exchange. 

On the other hand we do want to modify NAT-T a bit, at lest say that
the dynamically updating addresses is MUST, so we might want to
clarify this issue also.

Yes, I agree that doing probing of previously non-working addresses,
which now have unidirectional connection, can cause the connection to
loose packets in case there is NAT between both connections we are
trying to use. So I suggest we do not try to do probing on that case,
but simply start finding the working path only after we know there is
problem with current path.

As the path information is going to expire very quickly anyways, I am
not sure how much probing different paths while the current path still
works is going to help. 
-- 
[email protected]