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. 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? 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). 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. 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). 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. 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. 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. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec