[strongSwan] Strongswan MOBIKE support

[Tobias Brunner]

Hi Amit,

> Here I expect client to send UPDATE_SA_ADDRESS notification for new IP
> address 85.1.96.159 before actually start using this new IP address.
> However, client start sending DPD messages using new IP
> to which CISCO GW is not responding (As GW is not aware of new IP
> address)

And why would it not respond to that packet?  While it should not update
the IKE and IPsec SA addresses unless it receives an UPDATE_SA_ADDRESS
notify it should definitely respond to the packet and send its response
to the address and port it received it from (RFC 7296, section 2.11):

  An implementation MUST accept incoming requests even if the source
  port is not 500 or 4500, and MUST respond to the address and port
  from which the request was received.

This could be relevant, for instance, if a NAT device behind which a
client is located gets restarted so that the NAT mapping changes.  The
client won't notice that and not trigger an address update.  However,
the next DPD that's sent by the client will come from a different port
and maybe IP and unless the responder replies to that message the client
will never learn that the NAT mapping has changed to trigger an address
update (with MOBIKE NAT-D payloads are added to DPDs to detect this, see
section 3.8. of RFC 4555).

So while the host should respond normally to the message it should not
automatically update the IKE or IPsec SA addresses, that is, the
behavior defined in RFC 7296, section 2.23, which covers the automatic
address update is slightly changed (again, section 3.8. of RFC 4555):

   When MOBIKE is in use, the dynamic updates, where the peer address
   and port are updated from the last valid authenticated packet, work
   in a slightly different fashion.  The host not behind a NAT MUST NOT
   use these dynamic updates for IKEv2 packets, but MAY use them for
   ESP packets.  This ensures that an INFORMATIONAL exchange that does
   not contain UPDATE_SA_ADDRESSES does not cause any changes, allowing
   it to be used for, e.g., testing whether a particular path works.

The latter is exactly what strongSwan is doing, which is also described
in section 3.10. of RFC 4555:

  If required by its address selection policy, the initiator can use
  normal IKEv2 INFORMATIONAL request/response messages to test whether
  a certain path works.

Regards,
Tobias