Re: [IPsec] Additional charter items 1/4: Responder MOBIKE

["Valery Smyslov" <[e-mail]>]

Hi Tero,

> Valery Smyslov writes:
> > 3. MOBIKE. In current MOBIKE only initial initiator can initiate change of IP addresses.
> >      If this problem is solved, then this is the best choice for load sharing clusters.
> 
> Mobike is symmetric in IKEv2 level. Either end can have multiple IP
> addresses and can change the address at will. 

This is true. However, it is the original initiator who decides which addresses to use.
The original responder mostly plays passive role, only informing the initiator
which addresses are available.

> The problem is that you
> want something else than that, i.e., you do not want responder to
> change IP address and start using that as you can with MOBIKE. I think
> what you are really wanting is to responder to signal and ask for the
> initiator to change the address because you assume there is NAT
> between and if the responder just starts sending packets from new
> source IP address then they do not reach the initiator?

Yes.

> Note, the initiator do select the address pair to be used in the IPsec
> SA, but for the IKEv2 SA the exchange initiator selects which address
> pair is used. (RFC4555 section 2.1, last sentence of the 2nd
> paragraph).

It states that " the exchange initiator _can_ decide which addresses are used."
While he/she definitely can, the exchange would fail in case of restricted
NAT if the responder initiated the exchange from the IP address 
the NAT box has no mapping for.

> Also I think this can also already be done using standard RFC4555
> mobike. In the section 3.5 says when the initiator should change the
> address and one of the examples it gives is:
> 
>    o  An INFORMATIONAL request containing an ADDITIONAL_IP4_ADDRESS,
>       ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification
>       is received. This means the peer's addresses may have changed.
>       This is particularly important if the announced set of addresses
>       no longer contains the currently used address.
> 
> The responder can simply do following describined in the RFC4555
> section 3.6:
> 
>    There is one additional complication: when the responder wants to
>    update the address set, the currently used addresses may no longer
>    work. In this case, the responder uses the additional address list
>    received from the initiator, and the list of its own addresses, to
>    determine which addresses to use for sending the INFORMATIONAL
>    request. This is the only time the responder uses the additional
>    address list received from the initiator.

If original responder used its address the NAT box has no
mapping for yet, the exchange would fail.

> I.e., if it wants to move initiator from IP_R1 to IP_R2 it simply
> sends INFORMATIONAL exchange with source address of IP_R2 to IP_Ix and
> sends ADDITIONAL_*_ADDRESS or NO_ADDITIONAL_ADDRESSES describing the
> usable addresses and when initiator sees this it will immediately
> trigger to change the addresses used for IKEv2 SA and IPsec SA.
> 
> Of course one of the issues that if there is restricted NAT between
> hosts then packet from IP_R2 will not reach the initiator, unless the
> initiator has opened that port pair also in the NAT (which it can do
> by sending probe/keepalive packets out to the responder using all
> address from the responder).

In MOBIKE the initiator is not obliged to do this. Section 3.10:

   Implementations MAY do path testing even if
   the path currently being used is working to, for example, detect when
   a better (but previously unavailable) path becomes available.

> So at least the charter text is misleading, as I think this can
> already be done without any problems with MOBIKE as long as there is
> no NATs between, and even if there is NAT, the initiator can simply
> send keepalives for all responder addresses, and then it works. 

If there is no NAT in between, then there is no problem.

In real life there is a NAT in most cases. And while in presence
of NAT in theory unmodified MOBIKE _may_ work, there are too many 
vague places in the RFC that makes this problematic:
 - the initiator is not obliged to probe addresses other than the currently used ones
 - even if it probes, it may do it too rarely, so that the created NAT mapping 
   will expire

So, there is no guarantee for a cluster that the operation
of moving a client from one node to another will succeed.
I'd like such operations to be more deterministic.

> Note, that even in that case there is no protocol changes with them, and
> even if the address update from responder never reaches the initiator
> the MOBIKE still works, as long as the responders stops responding to
> the IP_R1 address (i.e., the address where it wants the initiator to
> move away from).
> 
> I.e., if responder has IP_R1 and IP_R2 addresses, and initiator is
> using IP_R1, and responder wants it to stop using it and move to
> IP_R2, then it is simply enough to stop responding to packets coming
> to the IP_R1. The initiator will detect this and move to use IP_R2...
> Yes, there will be short delay causing packets to be lost in this
> case. 

We seem to have different view of what "short" means :-)

The initiator doesn't sent liveness checks continuously.
It start probing current path if it suspects there is something wrong with it,
e.g. there is no IPsec packets from the responder for some period
of time. This period cannot be too short, it is usually tens of seconds 
to minute. Then, when starting probing the current path the initiator 
performs several retransmissions before giving up. And again, the timeout
cannot be too short, it is usually at least ten seconds, more likely 
about a minute. So your "short" delay is at least about a minute,
or even more. 

I don't think this delay is appropriate for any real-time traffic.

Needless to say that this approach also complicates cluster implementation.
To move a client from one node to another the cluster needs first to
send ADDITIONAL_*_ADDRESS that contains only the address of the node
the cluster wants to move client to. Then the IKE SA state must be transferred 
to a new node and the current node must stop responding to this client.
Then the cluster would wait until the client detects the failure and switches
itself to a new node. And there is also a chance that there are some IKE exchanges 
in progress, so if the node stops responding the exchanges could time out the and
the IKE SA would be deleted before the movement takes place (in my proposal
the MOBIKE is combined with RFC6311 exchange to make this working)...

> This delay will be eliminiated if the address update from
> responder reached initiator, i.e., if the initiator kept the ports
> open in NAT or if there is no NAT between.

There is absolutely no guarantee that it will work.
I'd like to have something more reliable.

Regards,
Valery.

> --
> [e-mail]