RE: issue 11 -- window size

--- Tero Kivinen <[email protected]> wrote:
> [email protected] writes:
> > I think it is useful to allow path testing even
> when the current
> > path is working, and the protocol should support
> doing this 
> > without disrupting ongoing communication (which
> does not seem
> > to be possible in your proposal).
> 
> It is possible, the protocol just needs to be
> written so it supports
> it. If you want to get it working with IKEv2 NAT-T
> you need to add
> modify the NAT-T behavior when using MOBIKE little
> more (You need to
> modify the NAT-T behavior in all cases)
>  
> > (E.g., suppose we have two interfaces, one very
> fast and cheap, 
> > second one very slow and expensive. If the first
> one has a temporary 
> > problem, and we switch to the second one, we want
> to switch back 
> > when possible even if the second interface keeps
> on working forever.)
> 
> Then you simply say that only N(MOVE TRAFFIC) is the
> only method of
> updating the addresses. I.e. disable dynamic
> updating of IKEv2 NAT-T
> (it is already allowed as dynamic update is SHOULD
> not MUST). 

I agree that this is one possibility i.e if the peer
has indicated MOBIKE support, then disable NAT-T like
updates. Expect that the peer will explicitly update
the addresses.

To some extent, this is needed even when PATH_TEST
message is a separate message i.e when the PATH_TEST
is processed, you don't update the addresses of the
SAs yet. Somehow this looks cleaner to me :-)

If there are several paths and some of them contains
NAT, i am assuming that Tero's proposal can detect
them (inspite of the constraint that the retransmitted
message cannot be modified). If this is getting into
too much detail, i will wait :-)

-mohan



> -- 
> [email protected]
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
>