[strongSwan-dev] Fwd: MOBIKE support

[Tobias Brunner]

Hi Patricia,

>     00[DMN] Starting IKEv2 charon daemon (strongSwan 4.4.1)

Can you try your scenario with a newer version?  We actually changed 
several aspects of the MOBIKE implementation with 4.5.0 (some details 
below).

> If I disable the eth0 interface, strongswan updates at first the IP
> available pool sending an INFORMATIONAL[ N(ADD_4_ADDR) ] from the eth1
> interface (the unique interface available) and then sends the update
> address (INFORMATIONAL [ N(UPD_SA_ADDR) N(NATD_S_IP) N(NATD_D_IP)
> N(COOKIE2) ].

The first INFORMATIONAL exchange you are seeing is a path probe message 
to check if a specific combination of local and remote addresses is 
valid.  Before 4.5.0 ADDITIONAL_IP*_ADDRESS payloads were added to these 
exchanges.  In newer releases you would only see empty INFORMATIONAL 
exchanges and then the exchange containing the UPDATE_SA_ADDRESSES etc.

> Why it doesn't send the N(UPD_SA_ADDR) first of all?

Charon first checks for a valid path between the two peers.  Only if it 
finds one it sends an UPDATE_SA_ADDRESSES payload to update the 
endpoints of the IPsec SA.

 > The responder peer can accept packets from other IPs without receive
 > the N(UPD_SA_ADDR)?

I'm not sure what you are referring to here.  If you refer to the 
dynamic updates as described in RFC 5996, Section 2.23, then the answer 
is no since MOBIKE explicitly disallows updates for messages that do not 
contain an UPDATE_SA_ADDRESSES payload.  For ESP packets the answer 
might be yes, that is, responders may accept authenticated packets from 
a different IP address than originally configured.  But charon actually 
does not update the locally installed IPsec policies until it sends the 
UPD_SA_ADDR.

> Finally, when the initiator peer has only one interface available and it
> sends the INFORMATIONAL[ N(ADD_4_ADDR) ] to update the list, why doesn't
> send a  INFORMATIONAL[ N(NO_ADD_ADDR) ]?

As I wrote above these path probe exchanges do not contain any 
ADD_*_ADDR or NO_ADD_ADDR payloads in newer releases.  That an 
ADD_*_ADDR payload was added instead of a NO_ADD_ADDR payload was simply 
a bug.

Regards,
Tobias