Re: Proposal for revised charter

Yafan An writes:
> I am not a regular reader of the MOBIKE list, and sorry I am late to
> make this proposal. But I bring it out anyway for your comments if
> interested.
> 
> I think we should add more support in MOBIKE for allowing "simple
> redirect" from one server to another. Although the draft has stated
> clearly that load-balancing is not an objective, but simple redirect has
> much more uses than load-balancing, such as redirecting a client from
> the old server to a new one after moving to a new location. The value of
> this is that it enables redirection problem to be solved at the IKE
> level, in stead of having to resort to application level, which takes
> more roundtrips.
> 
> I believe such enhancement can be achieved by defining new instruction
> parameters in the place of ADDITIONAL_IP?_ADDRESS, and complete the
> description of additional handlings.

Such operation can already be done with the current protocol, but it
is bit slow in case of NATs. I.e. the server will announce the new
address in the N(ADDITIONAL_IP*_ADDRESS) notify of the initial
exchange, and immediately after that it updates the list of additional
addresses and removes the old address from the list. As the address
used for that notification is included to the list implicitly then it
needs to send that notify from the some other address than the old
address it wants to get rid of. This means that if the initiator is
behind restricted nat it cannot receive those messages as they arrive
to the address it is not using.

In case of the NAT the responder needs to wait for the initiator to
start any IKE message to it, and not to reply to the old address, only
to the new address (i.e drop all requests coming to old address, and
wait for the initiator to switch to new address). This way the
initiator will update the SAs to new address, and after that responder
can send new notify and remove the old address from the address list.

So this can already be done with the current protocol even if the
other end does not know anything about this feature. There could be
optimizations done to the protocol if we modify the protocol, but as
the protocol is already in the rfc editor queue, we are not going to
do it now. 
-- 
[email protected]